Een kwalitatief betere applicatie begint bij jezelf
Als software engineer zijn we verantwoordelijk voor het bouwen van een applicatie. Voor een opdrachtgever is kwaliteit van een applicatie meestal niet zichtbaar waardoor het lijkt alsof er maar één ding belangrijk is en dat is de functionaliteit.Het gebeurd dan ook vaak dat er wordt gekozen voor meer functionaliteit ten koste van de kwaliteit of veiligheid van de applicatie. En dat is waar ik het met jullie over wil hebben: software kwaliteit.
Alle software engineers kennen het belang van goede kwaliteit software wel. Wanneer de kwaliteit niet op orde is kan dat later problemen geven met het onderhouden van de applicatie, kunnen er gemakkelijker bugs geïntroduceerd worden en kan de code minder gemakkelijk overgedragen worden naar een beheer team. Al deze nadelen spelen in de toekomst en dat is dan ook waarschijnlijk waarom er vaak voor wordt gekozen om toch maar die extra functionaliteit in te bouwen in plaats van die extra test of door een ander stuk code minder robuust te maken dan eigenlijk nodig is.
Waarmee ik niet wil zeggen dat een lagere kwaliteit altijd slecht is, maar je moet er in ieder geval goed over nagedacht hebben. Waarbij je in acht neemt hoe belangrijk het systeem in het ecosysteem is, hoe lang het nog gebruikt en onderhouden gaat worden en nog wat andere criteria die mee kunnen spelen bij zo een beslissing.
Het is dan ook onze verantwoordelijkheid als software engineers om de opdrachtgever of de product owner ervan te overtuigen dat er meer tijd in software kwaliteit gestoken moet worden en dat wij daar ook de tooling voor krijgen die wij nodig achten. Je kan dan denken aan tools als SonarQube, Gremlin of Fortify.
Nu is het natuurlijk zo dat dit allemaal geld kost en een opdrachtgever of product owner de kosten graag laag houdt en dan is het logisch dat hij liever nieuwe features wil in plaats van betere kwaliteit als hem niet uitgelegd wordt waarom hij die kwaliteit nodig heeft. Kwaliteit is namelijk niet iets tastbaars waar je de nieuwe features wel kan zien. Aan ons dan de taak om hem of haar van de juiste informatie te voorzien zodat de opdrachtgever of product owner een goed afgewogen beslissing kan maken. Wij zullen moeten vertellen dat slechte kwaliteit in de lange run ook extra kosten betekent, meestal meer dan wanneer je het aan het begin goed doet. Wij zullen moeten uitleggen dat een SonarQube inderdaad geld kost, maar dat je hierdoor wel een kwaliteitscheck in je pipeline kan inbouwen waardoor je wederom op de lange termijn geld zal besparen.
Wanneer je dan een SonarQube hebt zal je deze ook daadwerkelijk moeten gaan gebruiken. Dat betekent dat je SonarQube in je build moet hangen en ervoor zorgt dat je bij pull requests een check hebt op SonarQube. De policy moet zo zijn dat je pull request niet gemerged kan worden met de master branch zonder dat je een groene quality gate op SonarQube hebt. Wanneer je dat niet doet is de kans erg groot dat het niemand opvalt dat de kwaliteit van de code onder jullie afgesproken standaard is en zal er dus ook niets mee gedaan worden.
Een ander belangrijk aspect van werken met SonarQube is dat je de regels goed afstemt met de regels die jullie binnen jullie team of binnen de organisatie hanteren. Daarna kan je kijken naar wat jullie quality gate is. De quality gate is een ondergrens van wat jullie acceptabel vinden voor het aantal issues en test coverage. Wanneer je onder deze grens komt zal je ervoor moeten zorgen dat je de issues oplost tot je weer kwaliteit hebt die jullie binnen de organisatie of het team verwachten.
Nu zul je vast denken, “ ja dat is leuk, maar ik ben al 3 jaar bezig met deze applicatie en heb nooit SonarQube gebruikt. Dus voor mij is het nu te laat”. Dat is gelukkig niet het geval, ook bij bestaande projecten kan je SonarQube gebruiken om de kwaliteit van de applicatie omhoog te krijgen. Je kan de quality gate zo instellen dat hij niet naar de oude code kijkt bij het bepalen of je code voldoet aan de standaard. Hierdoor zal je enkel de meldingen die je zelf hebt geïntroduceerd met je pull request hoeven op te lossen. Dit kan volledig nieuwe code zijn, maar ook oude code die je hebt aangeraakt. Hierdoor wordt je applicatie elk pull request steeds een stukje beter zonder dat je alle issues in één keer hoeft op te lossen.
In het kort vind ik dat wij als software engineers meer verantwoordelijkheid moeten pakken over de kwaliteit die we opleveren. Als er iets mis gaat kan je niet zeggen “we hadden te weinig tijd”. Als dat je enige excuus is, dan heb je niet goed genoeg uitgelegd waarom jullie tijd nodig hebben voor de kwaliteit van de applicatie. We zullen eerst moeten kijken naar onszelf, hebben wij er alles aan gedaan om de kwaliteit wel op het niveau te brengen waar wij achter kunnen staan welke in verhouding staat tot de levensduur en hoe belangrijk het systeem is. Als het antwoordt nee is, dan is het in eerste instantie onze fout. Wij zijn de specialisten en zullen onze opdrachtgevers en product owners van de juiste informatie moeten voorzien en niet andersom.