Codekwaliteit

Waarom?

Bij goede code moet je met meerdere zaken rekening houden. Denk aan leesbaarheid, onderhoudbaarheid en flexibiliteit. Vooral in teamverband zijn deze zaken erg belangrijk. Ontwikkelaars moeten namelijk met elkaars code werken.

Stel een klant wil iets aanpassen of uitbreiden aan zijn bestaande software. Een ontwikkelaar moet dan een stuk code aanpassen dat meestal door een andere developer is ontwikkeld. Als de ontwikkelaar vervolgens niet begrijpt wat er gebeurt, kosten de werkzaamheden veel tijd. Dit kan komen omdat de code niet onderhoudbaar of flexibel is. Het wordt lastig om de wijziging op een simpele manier door te voeren.

Slecht leesbare code (spaghetti code) kan ook leiden tot bugs. Daarnaast kan het invloed hebben op de snelheid en de veiligheidskwetsbaarheden van het systeem. Waarom? Als je code niet te begrijpen is door een medeontwikkelaar (of door jezelf als je later naar je code terugkijkt), kun je er niet vanuit gaan dat de code precies uitvoert wat functioneel beschreven is. Dan ontstaan er misverstanden over hoe de code zou moeten werken.

Hoe? 

We begrijpen nu allemaal waarom goede code belangrijk is, maar hoe waarborgen we dit? Daar zijn verschillende richtlijnen en hulpmiddelen voor. Zo maken we bij Covadis gebruik van een ontwikkelstraat waarin we verschillende elementen testen. Deze ontwikkelstraat is geïntegreerd in onze Azure DevOps omgeving (ook bekend als VSO of VSTS). Dit is tevens onze source control omgeving en de plek waar al onze work items zijn gedefinieerd. Zo is ons gehele ontwikkelproces gecentraliseerd. 

Quality gate 

Per project wordt binnen onze ontwikkelstraat de code gecompileerd, getest en gecheckt op kwaliteit met behulp van SonarQube. Dit is onze zogeheten quality gate. SonarQube detecteert onder anderen bugs, vulnerabilities en code smells. Het is de bedoeling dat pas wanneer SonarQube groen licht geeft, de nieuwe code naar een testomgeving gebracht wordt. Op deze manier waarborgen we de codekwaliteit in ieder geval op een bepaald niveau.  

Code reviews 

Naast SonarQube reviewen ontwikkelaars elkaars code via een pull-request. Hiermee controleren we extra op potentiele functionele en technische fouten. Als de betreffende reviewer de code niet begrijpt, is er dus een verhoogd risico op fouten. De reviewer kan dan niet goed controleren of de geschreven code doet wat het moet doen. Het reviewen van code heeft ook nog een ander voordeel. Ontwikkelaars  leren dan van elkaars code. De ene ontwikkelaar heeft misschien meer kennis over een onderwerp of techniek dan de andere ontwikkelaar. Door elkaars code te reviewen kan de ander ook kennis opdoen over het betreffende onderwerp. 

Testen 

Het schrijven van tests is de andere manier om te controleren of de code doet wat het moet doen. Je kunt voor het systeem verschillende soorten tests maken. Unit tests zijn een veel gebruikte vorm. Een unit test wordt geschreven om een klein stukje code te kunnen testen zonder afhankelijkheden te gebruiken binnen deze test. Door alle stukjes apart en onafhankelijk van elkaar te testen, bereik je een soort keten over je project. 

Over het schrijven van automatische tests valt nog veel meer te vertellen, maar ik vind dat unit tests vooral de basis moeten leggen binnen een project. Andere vormen van testen zoals integration tests, gui tests, smoke tests zijn ook erg handig. 

Richtlijnen  

Leesbaarheid, onderhoudbaarheid en flexibiliteit zijn afhankelijk van de structuur van de code. Om dit in goede banen te leiden zijn er richtlijnen die ons daarbij helpen. 

• SOLID

Single Responsibility Principle: Een klasse mag maar één verantwoordelijkheid hebben

Open / Closed Principle: Een object moet open staan voor uitbreiding, maar gesloten voor wijzigingen. 

Liskov Subsitution Principle: Objecten zouden vervangbaar moeten zijn door instanties van hun subtypes zonder dat het de werking van het programma beïnvloedt. 

Interface Segregation Principle: Meerdere specifieke interfaces zijn beter dan één algemene interface. 

Dependency Invsersion Principle: Klassen zouden afhankelijk moeten zijn van abstracties en niet van concrete implementaties. 

• KISS

Keep It Simple and Stupid: De naam van deze richtlijn zegt eigenlijk alles 😉.

• DRY

Don’t Repeat Youreself: Twee keer dezelfde code schrijven levert je ook twee keer onderhoudskosten op.

• YAGNI

You Aren’t Gonna Need It: Een ontwikkelaar houdt van ontwikkelen en bedenkt soms een hoop handige functies die hij of zij in de toekomst nodig meent te hebben. Dit zorgt voor extra onderhoudskosten. Daarnaast vervuilt het de code met functionaliteit die misschien nooit gebruikt wordt.

xkcd.com