Onderhoudbaarheid tip 2: maak analyseerbaarheid en complexiteit zichtbaar

Door Victor van der Hulst In Smart@Vantage

Dit is deel drie over het belang van onderhoudbaarheid van applicaties. In het eerste deel hebben we stilgestaan bij het belang van onderhoudbaarheid van applicaties. Hoe onderhoudbaarheid wordt omschreven en hoe technical debt de onderhoudhaarheid negatief beïnvloedt. Vorig week is het belang van een Agile ontwikkelaanpak de revue gepasseerd. In dit deel sta ik stil bij het kunnen inschatten van de hoeveelheid technical debt.

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.

onderhoudbaarheid-tip-2-maak-analyseerbaarheid-en-complexiteit-zichtbaar-project-dashboard-blog-victor

Refactoring

Idealiter werkt elk development team met een statische code analyse tool om inzicht te krijgen in de trend van kwaliteit en onderhoudbaarheid. In het team wordt de uitkomst elke sprint besproken en worden eventuele acties op de backlog geplaatst. Acties kennen een handmatige review voordat het bewuste onderdeel van de code wordt aangemerkt voor 

refactoring. Met deze aanpak wordt het development team structureel gewezen op de onderhoudbaarheid van de code, zo objectief mogelijk. Nu duidelijk is wat de onderhoudbaarheid is en waar de technical debt zich bevindt, kan gestart worden met refactoring. De komende weken staan we stil bij de andere vijf tips om de onderhoudbaarheid, en daarmee de productiviteit en wendbaarheid, van maatwerk applicaties op het gewenste niveau te brengen en te houden. Volgende week tip drie:

Refactor met korte termijn doelen.

Meer informatie

victor-van-der-hulst

Victor van der Hulst

Managing Consultant

+31 6 22 98 68 76 Stuur Victor een e-mail

Reacties

Er zijn nog geen reacties op dit bericht.

Plaats een reactie

Dit veld is verplicht.

Vul een geldig e-mailadres in.

Dit veld is verplicht.