Onderhoudbaarheid van applicaties: een onderschatte kostenpost. Zeven tips

Wat is onderhoudbaarheid en waarom is het belangrijk?

Onderhoudbaarheid van software ((ISO 25010: https://nl.wikipedia.org/wiki/ISO_25010) wordt vaak onderverdeeld in:
* Modulariteit: de mate waarin een systeem of computerprogramma opgebouwd is in losstaande componenten zodat wijzigingen van een component minimale impact heeft op andere componenten.
* Herbruikbaarheid: de mate waarin een bestaand onderdeel gebruikt kan worden in meer dan één systeem of bij het bouwen van een nieuw onderdeel.
* Analyseerbaarheid: de mate waarin het mogelijk is om effectief en efficiënt de impact, van een geplande verandering van één of meer onderdelen, op een product of systeem te beoordelen, om afwijkingen en/of foutoorzaken van een product vast te stellen of om onderdelen te identificeren die gewijzigd moeten worden.
* Wijzigbaarheid: de mate waarin een product of systeem effectief en efficiënt gewijzigd kan worden zonder fouten of kwaliteitsvermindering tot gevolg.
* Testbaarheid: de mate waarin effectief en efficiënt testcriteria vastgesteld kunnen worden voor een systeem, product of component en waarin tests uitgevoerd kunnen worden om vast te stellen of aan die criteria is voldaan. Kort gezegd wordt de mate van onderhoudbaarheid van software bepaald door de

modulariteit, herbruikbaarheid, analyseerbaarheid, wijzigbaarheid en testbaarheid van de code. Dit lijkt een open deur, en toch zien we vaak dat onderhoudbaarheid uit het oog wordt verloren bij het (door)ontwikkelen van (bestaande of nieuwe) software. Tegelijkertijd kent onderhoudbaarheid een optimum; doorslaan werkt averechts. Na de eerste gemaakte functionaliteit begint al het onderhoud. Elke functionaliteit die wordt bijgebouwd, beïnvloedt de reeds bestaande code en wordt vooral ook beïnvloed door de bestaande code. Slecht opgezette code wordt steeds meer een last en verlaagt gaandeweg de productiviteit. Naar mate de hoeveelheid code groeit en de tijd verstrijkt, kan de productiviteit (en/of de kwaliteit) enorm dalen door de last van niet goed opgezette code. Dit wordt technical debt genoemd: schuld die nog uitstaat aan de techniek en die voor een goede werking en onderhoudbaarheid nog ingelost moet worden. In de volksmond spreken we dan snel over legacy. Technical debt is the invisible parts of your code that adds negative value to your system.

Technical debt

Matige onderhoudbaarheid wordt dus vaak veroorzaakt door technical debt. Hoewel geen fijn woord, wordt het wel eens code cancer genoemd. Technical debt ontstaat doordat tijdens het ontwikkelen short cuts worden genomen om snelheid te maken: code die werkt maar moeilijk is te onderhouden. Er wordt op voortgeborduurd en beetje bij beetje wordt de code besmet. De snelheid van veranderingen die de business najaagt, wakkert dit alleen maar aan. Vroeg of laat wordt deze code onbeheersbaar en verliest de business alle snelheid. Het inlossen van deze schuld (technical debt) wordt *refactoring** *genoemd. *Preventing technical debt is what allows development to be agile in the long run. *(https://www.atlassian.com/agile/technical-debt) In de komende weken staan we stil bij een zevental tips om de onderhoudbaarheid, en daarmee de productiviteit en wendbaarheid, van maatwerk applicaties op het gewenste niveau te brengen en te houden.
* Tip 1: Werk met een AGILE ontwikkelaanpak
* Tip 2: Maak analyseerbaarheid en complexiteit zichtbaar
* Tip 3: Refactor met korte termijn doelen
* Tip 4: Automatiseer testen