Code reviews zijn een essentieel onderdeel van het softwareontwikkelproces. Tijdens een code review kunnen we nieuwe kennis vergaren als developer, kennis onderling uitwisselen en de kwaliteit van ons product vaststellen. Dit is natuurlijk een mooi geschetst beeld, maar (ontwikkel)cultuur speelt hierbij een grote rol. In de praktijk zie je vaak genoeg dat een code review weinig meer inhoud, dan dat iemand alleen op de knop drukt omdat code snel naar productie moet.
In deze tweedelige reeks ga ik in op hoe je het code review proces goed vorm kan geven en op deze manier een gezonde code review cultuur kan creëren. In dit eerste deel: Hoe kun je een code review goed voorbereiden, zodat de reviewer er makkelijk en snel doorheen kan.
De stappen
De voorbereiding van een goede code review bestaat uit aantal stappen:
- De pull request klaarzetten.
- Het uitnodigen van je reviewers.
- Je checklist nalopen of alles gedaan is!
De pull request klaarzetten
Voor een reviewer is het uiteraard belangrijk dat hij/zij jouw pull request goed kan beoordelen. Dit kunnen we afdwingen door best practices te hanteren en te zorgen dat een review nooit meer dan vierhonderd regels code groot is en langer dan 60 minuten duurt.
Tevens is informatie verstrekken ook een pré. Dit kan worden gedaan door een duidelijke samenvatting te geven over de functionele werking van de programmeercode in de description van de pull request en te verwijzen naar waar iets te vinden is.
Tot slot is het handig om niet het gebruik van multimedia te onderschatten. Een duidelijke commit message en kleine hoeveelheden code helpen bij het creëren van een context voor de reviewer. Een afbeelding of video kan net de finishing touch zijn om iets duidelijk over te brengen richting degene die je uitnodigt. Het gebruik hiervan is afhankelijk van de tooling die je gebruikt. Sommige tools ondersteunen multimedia gebruik het description veld van de pull request, zoals Azure DevOps.
Wie nodig je uit om te reviewen?
Vaak staan we niet stil bij wie we uitnodigen voor de review. Daardoor verliezen we de mogelijkheid om waarde toe te voegen aan het (ontwikkel)proces. Deze waarde uit zich in verschillende doelen die een developer voor ogen kan hebben met de review, namelijk:
- Kwaliteit van het product verbeteren
- Kennisdeling
- Upscalen van de vaardigheden van developers
Het is dan ook belangrijk om stil te staan bij de opties die je hebt om iemand uit te nodigen voor jouw review. Verschillende rollen in het development team kunnen op verschillende manieren waardevolle feedback leveren op de code kwaliteit.
Tech lead
Tech leads hebben over het algemeen een breed scala aan ervaring waardoor zij in staat zijn om goede feedback te geven met betrekking tot coding practices en software architectuur. Tevens zijn zij vaak goed op de hoogte van marktontwikkelingen die wellicht van invloed kunnen zijn op bepaalde keuzes in het ontwikkelproces. Helaas zullen zij niet altijd kunnen reviewen in verband met andere werkzaamheden binnen de organisatie.
Medior & Senior developers
Collega’s met deze rol zijn van grote waarde in het review proces. Net als een tech lead hebben zij veel ervaring met ontwikkelen, waardoor zij goede feedback kunnen geven met betrekking tot programmeren en software architectuur. Mede door hun ervaring zouden zij sneller potentiële bugs moeten kunnen opsporen in een vroeg stadium.
Junior developers
De meerwaarde van beginnende professionals in het reviewproces is dat zij vaak een ander perspectief kunnen bieden dan meer ervaren collega’s. Ze hebben vaak een frisse blik op zaken en zijn minder bevooroordeeld op bepaalde technieken en practices. Ze zitten veel minder vast in bepaalde gedachtepatronen.
Testers
Een tester nodig je met een ander doel uit voor een review dan het aandragen van verbeteringen in de codebase van het project. Een dergelijk persoon heeft vaak heel goede functionele kennis over wat de software zou moeten doen, wat maakt dat hij in een vroeg stadium bugs en/of defecten kan opsporen.
Software architect
Een software architect kan als specialist een duidelijke visie geven over de applicatie en het systeem als geheel. Een dergelijke collega kan een grote bijdrage leveren in begin van een project wanneer de architectuur van de software nog in hoofdlijnen wordt uitgedacht/opgezet.
Anderzijds kan een architect ook verderop in het proces deelnemen, aangezien zij veelal ook als developer begonnen zijn en programmeerkennis hebben. Dit is afhankelijk van je eigen visie op het reviewproces.
Collega’s met een ander visie op programmeren
Het uitnodigen van iemand met een ander perspectief op programmeren kan confronterend zijn. Met name als deze persoon veranderingen adviseert die veel tijd kosten. Echter kan het altijd handig zijn om één persoon te hebben die geneigd is om andere oplossingen aan te dragen om zo tot de best mogelijk keuzes te komen.
Heb een checklist bij de hand!
Een checklist is ideaal om bij je code review ter hand te hebben. Op deze manier hoef je niet te onthouden waaraan een pull request moet voldoen. Een voorbeeld zou kunnen zijn:
- Doel van de pull request is duidelijk.
- Duidelijke uitleg over wat de feature of bug fix inhoudt.
- Clean code practices worden nageleefd.
- Voldoet aan de Definition of Done van het development team.
- Unit testen waar zinvol
Recap
In het kort:
- Een code review is NIET een commit met alleen een boodschap erbij.
- Werk met een checklist om het valideerbaar te maken.
- Sta stil bij wat jouw doel is van de review en acteer hierop!
Mocht je naar aanleiding van deze blog nog vragen of tips hebben die hierin niet zijn benoemd, neem dan gerust contact op met mij via gideonk@delta-n.nl.
Gideon Kuijpers – Software Developer
Lees ook deel 2 van dit blog Kwalitatieve Code reviews voor developers 2.
