Deze blogpost bestaat uit 2 delen, om niet in een keer te diep op de stof in te gaan. In het eerste deel zal ik meer uit de doeken doen waar het nou eigenlijk om gaat en geef ik concrete voorbeelden van metrieken en in het tweede en laatste deel ga ik deze op code loslaten om het praktische gebruik ervan te demonstreren.

me·ten (overgankelijk werkwoord, ook absoluut; mat, heeft gemeten)
1 de lengte, inhoud, temperatuur, oppervlakte enz. bepalen van

Meten is weten
Zoals het aloude spreekwoord zegt, meten is weten. Dat geldt al eeuwen voor beroepsvelden als architectuur en de bouw, maar ook voor wat exotischer zaken als bierbrouwerijen, de transportsector en de belastingdienst. Hierbij hebben we het over het meten van tastbare objecten (lengte van een muur, temperatuur van bier, aantal gereden kilometers en inkomende financiën), maar hoe zit dat in onze branche, waar tastbaarheid amper bestaat?

Vanaf het begin
Al in de jaren 60 van de vorige eeuw zijn er wetenschappers die zich met dit vraagstuk bezig houden. Wat valt er te meten aan software en hoe doe je dat? Uiteraard volgen daarop nog meer vragen, zoals; waarom zouden we meten aan software? Wat is het nut er van? Als we gemeten hebben en een uitkomst hebben, wat kunnen we daar dan mee doen? In het geval van de architectuur is dit natuurlijk eenvoudig; als een architect niet weet hoe lang een muur is, kan hij geen huis in elkaar laten zetten, omdat het wellicht niet past. Pure noodzaak en logica dus.

Jonge jaren
Om te weten wat we met uitkomsten willen, moeten we even de geschiedenis in duiken. De software industrie is jong. Ze bestaat pas enkele jaren in verhouding met industrieën die al eeuwen draaien. Logisch dus, dat de focus tot voor kort lag op het zich bewijzen. Maar, sinds de jaren negentig is er een kentering te merken, waar het nu toch ook blijkt te gaan om hoe goed de software is die gemaakt is, in plaats van alleen maar hoe functioneel deze is. Is de software over een paar jaar nog steeds te gebruiken en hoe eenvoudig is het om aanpassingen te maken, zelfs voor developers die geen ervaring hebben met het pakket? Is de software begrijpelijk? Coherent? Complex of juist niet?

Kwaliteit verhogen
Door aan broncode te gaan meten, kunnen we antwoord geven op bovenstaande vragen en daarmee, door juist om te gaan met de antwoorden, de kwaliteit van onze software verhogen. Kwaliteit zelf kan echter nog wel wat definitie gebruiken. Zo ziet de klant kwaliteit als iets dat goed en snel werkt en precies dat doet wat het moet doen. Een ontwikkelaar daarentegen, zal kwaliteit eerder zien als iets dat onderhoudbaar is, begrijpelijk is of herbruikbaar. Vanaf hier ligt de focus van dit artikel op de ontwikkelaar, functionaliteit wordt veelal getest met acceptatie tests. Ook hierbinnen zijn veel zaken te meten en het gebruik van metrieken niet vreemd, dit zijn echter andere metrieken dan hier genoemd gaan worden. Daarnaast is softwarekwaliteit niet een methode of een fase, maar een proces. Een proces wat constant de aandacht zou moeten krijgen en altijd aanwezig zou moeten zijn. Meten van broncode is echter wel een stap in dit proces. Zoals Drawing 1 laat zien, zijn control measurements vaak belangrijke input voor management keuzes, maar ook op kleinere schaal kunnen metrieken als input dienen voor ontwikkelaars.

Drawing 1: Softwarekwaliteit als process

Alhoewel sommige wetenschappers anders beweren, hebben metrieken over het algemeen nooit gepoogd HET antwoord te zijn tot het walhalla van kwaliteit, maar meer een middel om met eigen inzicht hier toe te komen. Door gebruik te maken van metrieken over complexiteit, kunnen we iets zeggen over hoe complex onze code is. We kunnen dan bijvoorbeeld zeggen dat de Understandability, zoals gedefinieerd in ISO 9126 omhoog gaat, wanneer de complexiteit omlaag gaat.
Daarnaast is het tegenwoordig trend om kleine, losstaande modules te maken die kunnen samenwerken met meerdere andere pakketten, het zgn. Commercial Off The Shelf (COTS). Hier is het natuurlijk belangrijk dat er een hoge mate van Interoperability is, wat weer bereikt kan worden door loosely coupled objects. Wanneer we deze coupling kunnen meten, kunnen we er er iets over zeggen en zelfs verbeteren wanneer dat nodig is.

Metrics
Een welbekende en veelgebruikte metriek is de Lines Of Code. Een variant hierop is de Lines Of Comment. Beide metrieken zijn nogal controversieel wanneer het gaat om definitie en gebruik, aangezien het onduidelijk is wat precies een regel code is en of witregels bijvoorbeeld ook meegeteld moeten worden. Daarnaast worden deze metrieken nog wel eens om de verkeerde redenen toegepast. Zo is het bij IBM wel voorgevallen dat er betaald werd per KLOC (1000 regels code)… geen slimme zet.

In 1976 publiceerde Thomas McCabe een paper over Cyclometic Complexity. Hierin legt hij een algoritmische formule uit die men kan gebruiken om van broncode te bepalen hoe complex deze is. Door simpelweg de knooppunten (nodes) van de edges (paden) af te trekken en hier 2 bij op te tellen, komt er een cijfer uit van 1 tot >50. Als algemene regel geldt hierbij dat >20 erg complexe stukken code zijn, en broncode met waardes van meer dan 50 zijn ‘ontestbaar’ door het grote aantal paden en knooppunten. Zoals je ziet, zegt complexiteit dus ook iets over Testability. From The Trench heeft hier overigens een goed artikel over.

Iets later, in 1994, hebben S.R.Chidamber en C.F. Kemerer een gehele set van metrieken bedacht, ook wel bekend als de C&K set. Hierin bevinden zich de volgende metrieken:

• Weighted Methods per Class (WMC)
• Depth of Inheritance Tree (DIT)
• Number Of Children (NOC)
• Coupling Between Object classes (CBO)
• Response For a Class (RFC)
• Lack of Cohesion in Methods (LCOM)

Ieder van deze metrieken zegt iets anders over broncode. Zo zeggen DIT en CBO iets over Interoperability en Changeability.

Net na McCabe, in 1977, presenteerde Maurice Halstead zijn Volume metrics. De bedoeling van deze metriek was het meten van codematige complexiteit en omvang. Halstead begon met het tellen van de operatoren en operanden, waarna hij hier een formule op los liet en zo de omvang kon meten. Helaas lijdt deze metriek aan dezelfde eigenschappen als Lines Of Code, namelijk dat er weinig valt te zeggen over hoe complex software is als de broncode meer operators of operanden gaat gebruiken, net als er niet gezegt kan worden dat software complexer wordt als er meer regels code zijn. Echter kan er wel een natuurlijk verband worden gelegd tussen meer regels code, of een grotere omvang en complexiteit en begrijpbaarheid, maar dit is dan puur op gevoelsbasis van de ontwikkelaar en is ook volledig afhankelijk van de implementatie en die is helaas niet te meten.

Drawing 2: Softwarekwaliteit voorbeelden

Dagelijks leven
Hoe vertalen deze metrieken zich nou naar het dagelijks leven van een programmeur, of zelfs naar die van een projectmanager? Door gebruik te maken van verschillende tools kan het meten aan code systematisch en automatisch gebeuren. Een aantal voorbeelden zijn: SourceMonitor, Metrics for Eclipse en RefactorIt. Wat natuurlijk veel handiger is, zijn automatische metingen op het moment dat er een build gemaakt wordt. Hudson bijvoorbeeld, is een uitstekende plek om metingen centraal te regelen. Op deze manier kunnen ontwikkelaars inspelen op de uitkomsten en kunnen projectmanagers de kwaliteit gemakkelijker beheersen.

Drawing 3: Softwarekwaliteit iteraties

Zoals in Drawing 3 te zien is, is meten in het dagelijks leven altijd een cyclus van meten, analyseren en aanpassen. Het analyseren van meetresultaten is niet altijd een triviale zaak, aangezien rekening gehouden moet worden met allerhande factoren die metingen kunnen beïnvloeden, zoals opzet. Ook het aanpassen van code aan de hand van de geanalyseerde gegevens is niet altijd gemakkelijk. Zo kan een methode of klasse lang en complex zijn, waar dit niet altijd even simpel te vereenvoudigen is. Ook kan een refactoring slag zaken nog wel eens complexer maken dan ze lijken, bijvoorbeeld door compacte methodes over meerdere klassen te verspreiden, alleen omdat het OO is.

Deel 2
Volgende keer meer hands-on met metrieken en meten aan software.