Onderhoudbaarheid tip 2: Maak analyseerbaarheid en complexiteit zichtbaar

Waarschijnlijk hebben we allemaal ervaring met een moeilijk onderhoudbare applicatie. Een applicatie die in de loop der tijd is uitgebouwd, waar diverse developers aan hebben gewerkt en die schijnbaar steeds lastiger is aan te passen. In de volksmond legacy genoemd. Enerzijds wordt de onderhoudbaarheid beïnvloed door het gehanteerde ontwikkelproces (zie deel 2) en anderzijds direct door de kwaliteit van het product (de code) zelf. Een objectieve meting van deze kwaliteit is dan ook doorlopend noodzakelijk.

Complexiteit en analyseerbaarheid

De grootste tijd- en geldslurpers van het doorvoeren van wijzigingen in bestaande applicaties zijn het opsporen en corrigeren van defecte code regels. Dit wordt vooral bepaald door de complexiteit en daarmee analyseerbaarheid van de code. Kan er snel worden bepaald waar de aanpassing moet worden doorgevoerd en of er ongewenste side effects zijn? Het is dan van belang oog te hebben voor de complexiteit van de code tijdens ontwikkeling. Dit kan zowel handmatig (review of audit) als geautomatiseerd met statische code analyse.

Handmatige reviews

Door regelmatig reviews te laten uitvoeren op gemaakte code (bijvoorbeeld peer reviews) kan onnodige complexiteit worden voorkomen. Ook dient er gekeken te worden naar consequente opbouw, structuur, code conventions en design patterns. Voordeel van deze reviews is dat conclusies worden getrokken met de context van de applicatie en het team in het achterhoofd. Nadeel is dat het tijd kost van developers en dat het een volwassen team vereist, waarin teamleden zich veilig voelen om bevindingen met elkaar te delen. In een onvolwassen team zien we vaak dat deze reviews weinig structurele problemen aan het licht brengen.

Statische code analyse

Voor statistische code analyse is tooling in te zetten die regelmatig de onderhoudbaarheid in kaart brengt. Deze tooling is te koppelen aan een Continuous Integration omgeving, zoals Jenkins of Microsoft Team Foundation Server. Voorbeeld hiervan is SonarQube, dat inzicht geeft in onder andere potentiële bugs, afwijkingen van coding standaarden, duplicaten, code coverage, complexiteit, spaghetti code en commentaar. Door middel van rule sets* *kunnen deze checks worden aangepast aan hetgeen belangrijk is binnen het team en de organisatie. Voordeel hiervan is dat er dagelijks inzicht is in de code kwaliteit (en daarmee de onderhoudbaarheid) en dat dit geen tijd kost van developers. Maar het belangrijkste voordeel is dat de trend zichtbaar wordt. Neemt de kwaliteit in de tijd juist toe of af? Dat is een belangrijk signaal om in het development team te bespreken.