Kwaliteit in softwareontwikkeling: meer dan alleen code

Kwaliteitsvolle software is eigenlijk best een complex begrip. Code die vandaag kwalitatief is, kan binnen een paar jaar als niet-kwalitatief bestempeld worden. Bij kwaliteit gaat het immers om meer dan alleen de structuur van de code of het voldoende testen van de werking ervan! Kwaliteit is voor ons een werkwoord, misschien kunnen we het zelfs nog beter beschrijven als een continu proces! Onze teams zijn hier tijdens hun werk dan ook constant mee bezig, maar hoe doen ze dit dan?

Het eerste punt waar we zorg voor moeten dragen, is dat de code die we schrijven ook “clean code” is. Clean code is een geheel van puntjes waar je als ontwikkelaar op moet letten om ervoor te zorgen dat de code die je schrijft gemakkelijk te lezen en te onderhouden is. Het gaat hier onder andere over het beperken van complexiteit, zorgen voor duidelijke naamgeving en nog veel meer. Over clean code is al heel veel geschreven, daarom ga ik er hier ook niet dieper op in. Ik kan je alvast wel aanbevelen om het boek “Clean Code” van Robert C. Martin eens te lezen als je hier meer over te weten wil komen! De belangrijkste vuistregel hier is dat je altijd probeert een bestand “cleaner” achter te laten als je klaar bent met je werk dan wanneer je het opende.

Kwaliteit wil ook zeggen dat je onderhoud zal moeten doen. Dat is met alles zo! Als je vandaag een nieuwe auto koopt, krijg je bij de levering een wagen die voldoet aan de geldende kwaliteitseisen . Je kan er dus gerust op zijn dat je er veilig mee op pad kan gaan. Je zal tijdens de levensduur je wagen regelmatig schoonmaken, je moet een onderhoudsschema volgen, … Doe je dat niet, dan zal de auto een minder lange levensduur hebben dan wanneer je dat wel zou gedaan hebben. Hetzelfde geldt bij software!

Software wordt dan misschien niet blootgesteld aan weer en wind, toch zal de kwaliteit ervan door de jaren heen verminderen als je er niets aan doet! Maar wat zijn dan deze onderhoudswerken? Bij java-applicaties moet je bijvoorbeeld regelmatig updates doen. Je wil geen verouderde versies gebruiken, want hierin kunnen problemen of kwetsbaarheden zitten die in nieuwe versies verholpen zijn.
Ook kan je de kwaliteit van software meten op basis van de werking van de beschikbare features. Software die vol met bugs zit, kan je moeilijk kwalitatief noemen. Dat wil je natuurlijk niet enkel controleren voor nieuwe zaken die je toevoegt, maar ook bestaande functionaliteit moet altijd blijven werken zoals het hoort.

Om de kwaliteit van je codebase te garanderen zijn er een aantal best practices die je in je team best kan integreren. Deze helpen je om de werkwijze van alle teamleden zo goed mogelijk op elkaar af te stemmen.

Het eerste waar je aan kan werken in het clean houden van de codebase. Dat is niet altijd eenvoudig, maar oefening baart kunst. Het maken van afspraken zoals eerder gezegd is hier een goed hulpmiddel bij. Begin daarom al met afspraken rond codestyle. Het komt de kwaliteit van de codebase niet ten goede als je aan de stijl van een stuk code kan zien wie dit geschreven heeft. Hier kan het gaan om “banale” zaken als indentatie, gebruik van whitespaces in je code,... maar ook naamgeving van classes, methods en variabelen valt hieronder. Er zijn tools die je hierbij kunnen helpen. Denk maar aan de linting-tools die door vele teams gebruikt worden. Deze gaan puur nakijken of de stijl van de code die je geschreven hebt conform is met de stijlregels die ingesteld zijn.

Een andere tip die je best in je teamwerking verwerkt, is het wegwerken van technical debt. Technical debt? Hieronder kan je verschillende dingen verstaan. De belangrijkste zaken die hier volgens mij onder vallen zijn onder andere het up to date houden van de versies van de gebruikte tools en het refactoren van stukken code die beter kunnen. Dit refactoren is iets dat je niet altijd als technical debt zal benoemen. Bepaalde refactorings nemen immers niet veel tijd in beslag en zijn nodig om nieuwe functionaliteit op een propere manier toe te kunnen voegen. Er zijn echter refactorings die uitgebreider zijn. Een goed voorbeeld hiervan is de aanbeveling van “spring cloud stream” om over te stappen naar het functionele programmeermodel. Hiervoor zijn meerdere wijzigingen nodig, die je niet zomaar snel even wil meenemen. Dergelijke grote wijzigingen kunnen dus best apart opgelijst worden als technical debt. Hiervan neem je met je team dan elke iteratie een aantal zaken op, zodat de technische backlog niet eindeloos blijft aandikken.

Je dependencies in lijn houden met de meest recente (stabiele) versie ervan, gaat vaak zonder veel grote problemen. Zeker als het gaat over een tussentijdse upgrades. Bij een major update kan het zijn dat er sommige dingen niet meer werken zoals voordien, maar dit zijn vaak dingen die in de release notes goed gedocumenteerd zijn door de maintainers.

Iets anders dat je ook vaak tegenkomt op projecten zijn afspraken die gemaakt worden over de gehanteerde codeerstijl. Het is me ooit al wel overkomen dat ik op een project terechtkwam, waar je duidelijk stukken code kon onderscheiden die geschreven waren door verschillende developers. Dit is iets dat je natuurlijk best zoveel mogelijk moet proberen te vermijden. Hier kan je gebruik maken van de kennis van je collega’s. Dat doe je bijvoorbeeld door code reviews te laten uitvoeren. Hier bekijkt een collega de code die iemand anders geschreven heeft om een bepaalde feature uit te werken. Je kijkt hier naar de uitgewerkte functionaliteit en je gaat na of er geen fouten in de implementatie aanwezig zijn. Een belangrijker deel van deze review is dat je ook gaat nakijken of de code voldoet aan de afgesproken standaarden. Je gaat hier vaak zaken uithalen waarin fouten gemaakt zijn tegen afgesproken naamgeving, maar ook verbeteringen in de structuur kunnen hier voorgesteld worden. Zo kan het zijn dat een andere developer ziet dat je bij een bepaald stuk code beter kan kiezen om een designpatroon toe te passen. Dit kan enerzijds zijn om de code duidelijker te maken, maar anderzijds kan het ook zeker gebruikt worden om de onderhoudsbaarheid of de uitbreidbaarheid van de code te verbeteren.

De code style kan je uiteraard ook nog op andere manieren laten controleren. Er bestaan verschillende tools die dit automatiseren. Denk hier bijvoorbeeld aan linting-tools of engines zoals sonar die je code gaan analyseren. Deze gaan enerzijds controleren of je alle conventies gerespecteerd hebt. Als er zaken niet in orde zijn, zullen deze weergegeven worden in de output van de scan. Veel van deze engines zijn ook configureerbaar, waardoor je de regels die gehanteerd worden eenvoudig kan aanpassen aan de afspraken binnen het team.

Tot slot wil ik ook nog even de nadruk leggen op het belang van testen om de kwaliteit van code te garanderen. Hier gaat het niet zozeer over de kwaliteit van de code zelf, maar wel over de kwaliteit van de uitgewerkte functionaliteit. Hier zijn verschillende soorten testen mogelijk. Enerzijds heb je natuurlijk de manuele testen. Hier gaat iemand uit het team zelf aan de slag om via de user interface de werking van functionaliteit te testen. Dit is natuurlijk iets dat redelijk arbeidsintensief is. Meer nog, de hoeveelheid werk groeit naarmate de applicatie groeit. Het is immers perfect mogelijk dat een werkende feature ineens niet meer werkt bij aanpassingen in de code. Daarom voorzien we in al onze projecten ook altijd grondige testsuites, die geautomatiseerd de werking van, zowel bestaande als nieuwe, code controleren.
Ook hier onderscheiden we verschillende soorten testen. Je hebt bijvoorbeeld de unit testen, integratietesten en end to end testen, elk met hun specifieke eigenschappen en niveau van isolatie.

Het grote voordeel van automatische testen is dat je ze heel vaak kan uitvoeren. Of beter nog, je kan dit automatiseren. Alle moderne CI/CD tools bieden de mogelijkheid om tijdens de pipeline testen geautomatiseerd uit te voeren. Hier kan je met een beetje configuratie zelfs een opsplitsing maken tussen verschillende soorten testen. Zo kan je bijvoorbeeld bij elke commit kiezen om alle unit testen uit te voeren, terwijl je de integratietesten enkel uitvoert als er een code change toegevoegd is aan een pull request. Hiermee kan je dan de build time in de hand houden, om zo toch ook de kosten een beetje te drukken.

In deze blogpost nam ik jullie mee in een reis van probleemoplossend denken naar het streven naar kwaliteit in software development. Want zeg nu zelf, kwalitatieve software op de markt brengen, dat willen we toch allemaal. Nog een belangrijk aspect voor het op de markt brengen van kwaliteitsvolle software is uiteraard het testen. Daarom leg ik jullie in een volgende blog meer uit over twee belangrijke aspecten van kwaliteitsvol programmeren: Test Driven Development (TDD) en Behavior-Driven Development (BDD)