Kwaliteit van code

In ons dagelijks werk schrijven wij enorm veel regels code om de websites en webapplicaties die wij bouwen te laten functioneren. Uiteraard kunnen hier bugs en typefouten ontstaan waar wij zelf, door de hoeveelheid code, als ontwikkelaar soms blind voor zijn.

Hoe zorgen wij er dan voor dat het opgeleverde product uiteindelijk toch goed in elkaar zit? Hier hebben wij een aantal methodes voor.

Test 1,2,3

Ten eerste het testen. Als ontwikkelaar testen wij zelf wat wij maken. Daarbovenop test een collega op een testomgeving het opgeleverde werk voor het naar de klant gaat die op een acceptatie-omgeving nogmaals het opgeleverde werk controleert voor het op productie wordt uitgerold.

Geautomatiseerde code inspectie

Naast het rigoureus testen door ons en de klant, maken wij gebruik van geautomatiseerde software, Jenkins en SonarCube, om unittests uit te voeren en de code na te lopen op overduidelijke bugs, typefouten en zogenaamde code smells of duplicate code. Door de rapportages van deze software door te nemen, kunnen we een aanzienlijk deel van de problemen verhelpen nog voordat de klant het opgeleverde werk te zien krijgt.

Beoordelen en bediscussiëren

Omdat we al onze code opslaan in een bewaarplaats, die we een ‘repository’ noemen, hebben we niet alleen een historisch overzicht van wie wat, wanneer en waarom heeft ingevoerd, maar hebben we ook de mogelijkheid om elkaars werk te beoordelen. Dit is nog voordat de code, het wijzigingsverzoek of de uitbreiding van de software wordt doorgevoerd op een ontwikkel- of testomgeving.

Dit beoordelen noemen wij ‘pull requests’. Na het uitvoeren van een wijziging uploadt de developer de wijziging naar de repository en doet een pull request om de wijziging te kunnen doorvoeren op de ontwikkelstraat. Daarbij wijst de ontwikkelaar een aantal collega’s aan die de wijziging moeten controleren en goedkeuren alvorens deze kan worden samengevoegd met de bestaande code.

Het voordeel van deze werkwijze is dat alle code door tenminste twee of drie paar ogen wordt bekeken en dat foutjes die anders over het hoofd worden gezien op deze manier kunnen worden voorkomen. Een tweede voordeel is dat de collega’s die de wijziging nakijken suggesties kunnen doen of commentaar kunnen leveren op de code, zodat bepaalde logica slimmer kan worden opgelost, code beter loopt, veiliger wordt gemaakt en in sommige gevallen zelfs sneller werkt.

(Tijd) Investeren om te winnen

Het principe van meer ogen zien meer dan één gaat met deze methode zeker op. Het nakijken van elkaars werk en het herschrijven van de code omdat een collega met een slimmere of betere aanpak komt kost extra ontwikkeltijd. Maar de kans dat er bugs sluipen in de software of dat een klant fouten ontdekt op een productieomgeving wordt hiermee vele malen kleiner waardoor er geen tijd verloren gaat aan het achteraf herstellen van bugs. Tevens word de code kwalitatief dusdanig goed dat onderhoud makkelijker wordt en dus ook minder kostbaar.