Tijdens een peer review bekijkt iemand het werk van een directe collega. Het doel is om kennisdeling en de kwaliteit van de oplossing te vergroten. Bij softwareteams gaat het specifiek om de broncode van een (web)applicatie. Het proces verloopt meestal als volgt:

• Developer A schrijft nieuwe code of wijzigt bestaande code.
• Developer A slaat de code op in een aparte branch in het versiebeheersysteem (Git, Subversion, etc) en geeft aan dat de code gereviewed kan worden middel een pull request.
• Een willekeurige collega, in dit geval Developer B, bekijkt de door A gemaakte oplossing.
  • Als Developer B verbeterpunten ziet, dan retourneert hij de code inclusief zijn of haar opmerkingen aan Developer A. Die gaat er vervolgens mee aan de slag. Zodra hij of zij klaar is, slaat hij de code weer op in het versiebeheersysteem en zal Developer B de code opnieuw bekijken.
  • Als er geen verbeterpunten meer zijn, dan voegt Developer B de code toe aan de juiste branch in het versiebeheersysteem (meestal de ‘master branch’). De code is dan opgenomen in de applicatie.

Naast peer code reviews bestaan er ook andere soorten reviews zoals die door externe specialisten. In dit artikel kijk ik alleen naar reviews door directe collega’s.

Een ander voordeel van code reviews is dat het aantal fouten afneemt. Het principe is eigenlijk heel eenvoudig: twee paar ogen zien nu eenmaal meer dan één. De reviewer bekijkt de code vanuit zijn eigen perceptie van het kennisdomein en de technische oplossing, en zal daardoor bugs kunnen identificeren die de oorspronkelijke auteur over het hoofd heeft gezien. Bovendien zit de kennis van de oplossing nog fris in het geheugen, waardoor het verhelpen van bugs sneller en gemakkelijker is dan als de fouten pas enkele weken, maanden of zelfs jaren later gevonden worden.

Het derde voordeel van code reviews is dat de secundaire kwaliteit toeneemt. Daarmee bedoel ik dat code doorgaans netter, beter gedocumenteerd, grondiger getest, beter gestructureerd en beter onderhoudbaar is. Dat heeft er mee te maken dat mensen nu eenmaal (veelal onbewust) netter werk opleveren als ze weten dat een ander er actief naar gaat kijken. Dit wordt ook wel het “Ego Effect” genoemd.

Het introduceren van code reviews in een development team lijkt gemakkelijk, maar in de praktijk is er een behoorlijk aantal valkuilen. Uit onze eigen ervaringen en die van andere teams hebben we de volgende aandachtspunten op een rij gezet:

• Stel zeker dat het team code reviews ziet als een positieve manier om van elkaar te leren. De auteur van de code kan immers iets leren van de reviewer, maar de reviewer kan ook iets leren van het werk van de auteur. Als de teamleden de reviews niet als een kans om te leren maar enkel als een verplicht controlemechanisme zien, dan ontstaat er tegenzin en verliezen de reviews een deel van hun kracht.
• Leg de focus van de review op of de code het juiste resultaat geeft en aansluit bij de architectuur van de applicatie – en niet op of de code precies jouw oplossingsrichting volgt. Bij veel ontwikkelteams ontaarden code reviews in discussies die feitelijk neerkomen op persoonlijke voorkeuren. Dat zou niet het geval mogen zijn. Discussies over bijvoorbeeld de stijl van programmeren of de beste architectuur zijn nuttig, maar dienen op andere momenten plaats te vinden.
• Benoem niet alleen fouten, maar zeker ook goede punten. Het geven, maar ook het ontvangen van kritiek, vraagt om serieuze sociale vaardigheden. Door niet alleen te kijken naar wat beter kan maar ook wat juist goed is, versterkt de samenwerking tussen de teamleden en krijgen reviews een positieve lading.

• Code reviews moeten binnen een zo kort mogelijke tijd gestart worden. Wanneer je code indient voor review, dan wil je immers niet pas dagen later feedback krijgen, want dan ben je vermoedelijk alweer met hele andere dingen bezig. Dat betekent echter niet dat een teamlid zijn of haar werk uit handen moet laten vallen om als een bezetene jouw code te bekijken. Maar over het algemeen zijn er meerdere momenten per dag waarop een teamlid tijd heeft om het eigen werk even te laten rusten en de code review uit te voeren.
• Werk altijd in tweetallen. Eén stukje code moet door één andere developer gereviewed worden, niet door meerdere. Anders krijgt de oorspronkelijke auteur met de inzichten van meerdere personen te maken en dat leidt al snel tot ongewilde discussies.
• Gebruik een tool als GitHub voor het reviewen van de code. Met dit soort tools is het erg gemakkelijk om op specifieke onderdelen van de code feedback te geven en daar vervolgens opvolging aan te geven. Dat wil overigens niet zeggen dat het bespreken van de review niet face-to-face kan plaatsvinden. Zeker als het commentaar wat ingrijpender is, dan is het aan te raden om even samen achter het scherm te kruipen en de opmerkingen door te spreken. Het is dus belangrijk om daar met elkaar de juiste balans in te vinden.
• Kijk niet alleen naar de geproduceerde applicatiecode, maar ook naar (de aanwezigheid van) tests en documentatie.