7 tips voor een high quality code review

Wat verstaan we onder een code review? In dit blog focussen we ons op nieuwe programmeercode die toegevoegd wordt aan een bestaande applicatie. We hebben het dus niet over het reviewen van alle code van nieuwe software. De code review die we hier behandelen, is een taak voor de developer of een ander teamlid om nieuwe code te controleren, feedback op deze code te geven te geven en deze uiteindelijk te accepteren. Deze review is onderdeel van een pull request. 

Zeven stappen op weg naar een high quality code review 

1. Zorg dat je de te reviewen code begrijpt

Ken je de context? Dat is de eerste vraag die je jezelf moet stellen bij een code review. Zorg dat je weet wat het doel is van nieuwe code en welk (gebruiks)voordeel deze moet opleveren. Het is daarbij cruciaal om elke regel supernauwkeurig regel te lezen, want één verkeerde regel kan al grote problemen veroorzaken. 

2. Check of de code niet onnodig complex is

Controleer of de code maintainable, clean en niet te lang is. Kijk eveneens kritisch naar de variable names. Uitschrijven is hierbij vaak beter dan afkorten, dan weten alle betrokken developers meteen wat je bedoelt. Let ook op ‘over-engineering’; is een stukje code niet onnodig generiek opgezet om rekening te houden met edge cases die nooit en te nimmer gaan plaatsvinden? Tegenwoordig heb je in veel programmeertalen de mogelijkheid om op één regel een itererende functie uit te voeren. Maar te veel van deze functies op één regel kunnen voor veel onduidelijkheid zorgen, dus beschrijf bij voorkeur één functionaliteit per regel.
 

3. Kan de code leiden tot een mindere performance? 

Merk je dat een applicatie slecht presteert? Naderhand is het lastig om te achterhalen waar dat ‘m in zit. Dus elk issue dat je nu al kan oplossen, levert je later veel potentiële tijdswinst op. Memory leaks komen bij veel oudere programmeertalen nog wel eens voor, omdat je daar meer handmatig moet doen. Check ook of je geopende processen in je code weer hebt afgesloten. Dergelijke onnodig lopende processen zijn ook een veelvoorkomende oorzaak van memory leaks. 

4. Controleer of de code doet wat je verwacht

Wees scherp op onverwacht gedrag van de geprogrammeerde code. Dit kan wel eens voorkomen in JavaScript. Een oorzaak kan bijvoorbeeld zijn het gebrek aan types binnen deze taal. Deze problemen kun je deels voorkomen door Typescript te gebruiken, maar controleer dan wel of alle variabelen en functies een type hebben. Vergeet ook niet de unit tests te controleren, want deze test is eigenlijk ook code en onderdeel van de code review. Zijn de unit tests nuttig? Raken ze de beoogde test cases wel? En begrijp je wat de unit test moet doen? 

5. Doe een final check

]Is de code schoon en klaar om te ‘mergen’ met de bestaande code? Ook dit zal voor een groot deel afgevangen worden door code analyse tools zoals SonarQube. Controleer bij de final check eveneens of comments en ‘console statements’ zijn verwijderd uit de code. Developers vergeten nog wel eens om deze weg te halen. En is de code consistent, ofwel in lijn met de gebruikte coding standards? Dat is ook iets om op te letten. 
 

6. Geef duidelijke feedback

Goed werk, je hebt jouw code review succesvol afgerond! Nu is het tijd dat het teamlid waarvoor je de review hebt gedaan eventuele wijzigingen in de code aanbrengen naar aanleiding van jouw bevindingen. Hoe zorg je dat die feedback goed overkomt? Wees duidelijk, zonder onaardig te worden. Dus vertel de developer niet alleen welke code hij moet veranderen, maar ook waarin hij die moet veranderen en waarom. Vooral dit laatste is belangrijk, zo voorkom je vragen, misverstanden en discussies. 

7. Wanneer druk je op ‘accept’? 

Dat blijft lastig om te bepalen en is afhankelijk verschillende factoren, zoals het belang van de software waar de nieuwe code in opgenomen wordt. Is dit een breaking applicatie, dan is zorgvuldigheid geboden. Daarnaast speelt mee hoelang het duurt om jouw suggesties uit de code review te realiseren. Kost dit uren of dagen? Neem tenslotte ook het belang van jouw feedback mee in je afweging om wel of niet op ‘accept’ te drukken. Zijn de issues die jouw code review aan het licht heeft gebracht groot of klein?
 

Meer tips of verder praten? 

Je weet nu hoe je een succesvolle code review uitvoert. Wil je meer tips of advies over het schrijven en reviewen van code? Neem contact op met Edward van Lieshout, Senior Frontend Developer bij Sogeti of bekijk zijn presentatie op QX Day: How to do a hq code review?(externe link)