Codekwaliteit

Vrijwel alle softwareontwikkelaars hameren erop dat code kwalitatief hoogwaardig geschreven wordt. Waarom is dat eigenlijk? Als het werkt dan werkt het toch? Wie of wat bepaalt wat goede code is? Dat ga ik in deze blog vertellen.

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.

Perfecte code bestaat niet

Ja, je leest het goed. Perfecte code bestaat niet. Iedere stakeholder (ontwikkelaar, tester, projectmanager, klant, etc.) heeft verschillende belangen. Hierom zal er altijd een spanningsveld zijn over wat de definitie van perfect is. Binnen een project is het heel lastig om de belangen van alle stakeholders te realiseren. Daarom moet je als team naar het doel kijken met wat je wil bereiken. Hier komen eventuele risico’s of prioriteiten bij om de hoek kijken.

Als ontwikkelaar kijk ik vaker naar risico’s op het gebied van leesbaarheid, onderhoudbaarheid en flexibiliteit. Stel je eens voor dat je een tool moet maken die eenmalig uitgevoerd wordt. Het risico dat deze tool in de toekomst vaak aangepast of uitgebreid moet worden is dan zeer laag. Terwijl de prioriteit misschien heel hoog is omdat de klant het nodig heeft. In dit scenario zijn onderhoudbaarheid en flexibiliteit minder belangrijk dan wanneer de tool elke dag voor verschillende modules wordt uitgevoerd.

Ik maak dagelijks in het werkveld mee dat het toepassen van de hier genoemde richtlijnen en hulpmiddelen helpt om makkelijker wijzigingen door te voeren. Het doel van deze blog is dat meer mensen (niet alleen ontwikkelaars) zich bewust worden van het belang van een hoge codekwaliteit.

Jeffrey Haen is één van de slimme software ontwikkelaars bij Covadis. Naast mooie software toepassingen bouwt hij ook hard aan zijn body. Zodoende komen zijn lengte en breedte in centimeters bijna overeen. Als centraal aanspreekpunt luisteren zijn collega’s bijna net zo goed naar zijn wijsheden als zijn trouwe viervoeter. Bovendien is Jeffrey een expert in boardgames, op het water, aan een kabel, in de golven.