Wat is het peerreviewen van code?

Peerreviewen is het proces waarbij een ontwikkelaar de code van een andere ontwikkelaar beoordeelt en feedback geeft. Het doel is om de kwaliteit van de code te verbeteren, fouten te ontdekken, en ervoor te zorgen dat de code voldoet aan de gestelde requirements en best practices. Tijdens een peer review wordt de code gecontroleerd op correctheid, leesbaarheid, modulariteit, testbaarheid, en performance. Het proces draagt bij aan de voortdurende verbetering van de codekwaliteit en helpt bij het delen van kennis binnen het team.

Hoe zit peerreviewen in elkaar?

Peerreviewen van code is een proces waarbij een collega-ontwikkelaar (de peer) de geschreven code van een andere ontwikkelaar beoordeelt en feedback geeft. Dit gebeurt meestal na de ontwikkelfase, maar voordat de code in de productieomgeving wordt geïntegreerd. Peer reviews zijn een essentieel onderdeel van het ontwikkelingsproces en dragen bij aan de kwaliteit, betrouwbaarheid en onderhoudbaarheid van de code.

Naast het doorlopen van de ontwikkelcyclus (van requirements naar functioneel ontwerp, technisch ontwerp, code, testen en oplevering), wordt van professionals verwacht dat zij actief feedback vragen, ontvangen, verwerken, geven en terugkoppelen. Dit geldt ook voor de programmacode die ze schrijven. Het peerreviewproces is daarbij een belangrijk moment om de kwaliteit van de code te waarborgen.

Het doel van peer review is niet alleen om bugs of fouten te vinden, maar ook om de code te verbeteren door middel van constructieve feedback. Het helpt ontwikkelaars om nieuwe inzichten op te doen, fouten te voorkomen en de code te verfijnen. Het proces zorgt ervoor dat de code voldoet aan de richtlijnen voor leesbaarheid, modulariteit, performance, en beveiliging.

Een belangrijk aspect van peer review is dat de code wordt beoordeeld met het oog op de requirements en het ontwerp. Een ontwikkelaar kan bijvoorbeeld tijdens een peer review gerichte vragen stellen, zoals: “Deze code geeft invulling aan requirement X, is ontworpen volgens Y en getest volgens Z. Kun je feedback geven over hoe goed de implementatie van het technische ontwerp in de code is doorgevoerd, en of de testen goed aansluiten bij de gestelde requirements?”

Het werkt toch…

Realiseer je dat zowel goede als matige code te compileren is, dus syntactisch goed wil nog niet zeggen dat de code goed is. Goede code is goed voor een reden, bijvoorbeeld dat het onderhoudbaar is of het herbruikbaar is. Het uitvoeren van peerreviews in de context van softwareontwikkeling is een belangrijk onderdeel van het leerproces. Het stelt je in staat om kritisch te denken, feedback te geven en te ontvangen, en van elkaar te leren. Hier is een set van algemene richtlijnen je kunt gebruiken voor het beoordelen van code geschreven in C#.

Tijdens een peer review wordt de code beoordeeld op de volgende punten:

  1. Correctheid: Is de code juist geïmplementeerd en levert deze het gewenste resultaat volgens de gestelde requirements?
  2. Leesbaarheid: Is de code goed leesbaar en begrijpelijk? Worden duidelijke namen gebruikt voor variabelen, functies en klassen? Is de code goed geformatteerd?
  3. Modulariteit en herbruikbaarheid: Is de code opgedeeld in kleine, modulaire eenheden die gemakkelijk te begrijpen, te testen en te hergebruiken zijn?
  4. Testbaarheid: Zijn er voldoende tests aanwezig, en dekken deze tests de relevante gevallen? Wordt de code correct getest?
  5. Performance: Is de code geoptimaliseerd, vooral op kritieke punten die de performance kunnen beïnvloeden?
  6. Beveiliging: Zijn er beveiligingsrisico’s in de code, zoals SQL-injecties of het niet goed omgaan met gevoelige gegevens?
  7. Conformiteit met richtlijnen: Is de code in lijn met de afgesproken coding standards, richtlijnen en best practices van het team of bedrijf?

Het is belangrijk om te benadrukken dat feedback tijdens peer review altijd constructief moet zijn. In plaats van de code of de ontwikkelaar zelf te bekritiseren, moet de feedback gericht zijn op het verbeteren van de codekwaliteit en het verkrijgen van inzichten om toekomstige fouten te voorkomen.

Door de code door meerdere ogen te laten beoordelen, wordt het risico op fouten en technische schuld verkleind, wat bijdraagt aan een hogere kwaliteit van de eindproduct.

Casus

Tijdens een sprint in een softwareproject werkte Mark hard aan een nieuwe functionaliteit voor het inloggen van gebruikers. Hij was trots op zijn werk en besloot de code snel af te ronden en door te sturen voor review. Mark had de businesslogica geïmplementeerd, maar was nog niet helemaal zeker van de optimalisatie van de foutafhandelingsmechanismen.

Sarah, een collega van Mark, kreeg de taak om de code te reviewen. Ze zag meteen dat er een paar foutafhandelingsscenario’s ontbraken, zoals wat er zou gebeuren als een netwerkverbinding verloren ging tijdens het inloggen. Daarnaast merkte ze op dat de foutmeldingen niet erg informatief waren voor de gebruiker.

Sarah gaf Mark constructieve feedback: “De logica ziet er goed uit, maar we moeten ervoor zorgen dat de foutmeldingen gebruiksvriendelijk zijn en de netwerkinstellingen robuuster maken.” Mark was dankbaar voor de feedback en werkte de verbeteringen snel bij.

Toen Mark de gewijzigde code weer testte, ontdekte hij een onverwachte bug die hij zelf niet had opgemerkt: een conflict in de manier waarop sessies werden beheerd. Het was pas door de review dat hij dit probleem ontdekte, en het had het project aanzienlijk vertraagd als het niet tijdig was aangepakt.

Het belang van de peer review werd voor Mark duidelijk: door de input van Sarah werd de code niet alleen robuuster en gebruiksvriendelijker, maar werden ook onopgemerkte problemen opgelost voordat ze de productiefase bereikten. Het gaf hem meer vertrouwen in de kwaliteit van zijn werk en hielp het team als geheel sneller vooruit.

Hoe gebruik je peerreviewen van code?

Als ontwikkelteam maak je afspraken wanneer peer reviews worden uitgevoerd, hoe ze worden uitgevoerd en aan wie het resultaat gecommuniceerd wordt. Het is goed gebruik om de peerreview op te nemen in de Definition of Done (DOD).

Gebruik de code richtlijnen van HBO-ICT.


Volgende stap: Uitleg beredeneren bouwkeuzes