Code review-cultuur en PR-best practices

Code review is geen poortwachterij — het is de manier waarop teams samen leren, eigenaarschap overdragen en de kwaliteit hoog houden. Een goede reviewcultuur tilt het hele team naar een hoger niveau; een slechte cultuur veroorzaakt knelpunten en wrevel.

1) Houd het klein (liefst minder dan 400 regels). 2) Schrijf een duidelijke beschrijving: waarom, wat en hoe je het test. 3) Voeg het ticket toe. 4) Voeg schermafbeeldingen of video’s toe voor wijzigingen in de gebruikersinterface. 5) Beoordeel je eigen diff voordat je beoordelaars vraagt.

Gebruik dezelfde conventionele voorvoegsels als bij commits: feat: add user profile page, fix: handle 404 in fetch wrapper, refactor: extract Avatar component. Veel teams genereren op basis hiervan wijzigingslogboeken.

De meeste teams gebruiken een PR-sjabloon — installeer het in .github/pull_request_template.md.

Loop voordat je beoordelaars vraagt je eigen diff regel voor regel door. Voeg opmerkingen toe waarin je niet-vanzelfsprekende keuzes uitlegt. Vaak ontdek je zo je eigen fouten voordat iemand anders dat hoeft te doen.

Een PR van 2.000 regels wordt zelden grondig beoordeeld. Splits hem op in: 1) refactoring (geen gedragswijziging), 2) nieuw gedrag, 3) afwerking van de gebruikersinterface. Zo is elk deel makkelijker te beoordelen en terug te draaien.

Formuleer feedback als vragen, niet als bevelen: ‘Wat vind je ervan om dit naar een hook te verplaatsen?’ werkt beter dan ‘verplaats dit’. Maak onderscheid tussen wat beslist moet worden opgelost en wat alleen prettig zou zijn. Gebruik voorvoegsels: nit:, question:, blocker:.

‘Dit is verwarrend’ vertelt de auteur niets. ‘Ik moest dit drie keer lezen om de vroege return te begrijpen — kunnen we een guard clause extraheren?’ geeft de auteur iets concreets om mee aan de slag te gaan.

Reageer positief op slimme oplossingen, goede naamgeving en nuttige tests. Dat moedigt zulke patronen aan en maakt de rest van de feedback minder scherp. PR’s waarop alleen kritiek komt, voelen vijandig aan.

Prettier handelt de opmaak af. ESLint handelt de stijl af. Verspil geen beoordelingsrondes aan tabs versus spaties. Als een stijlregel steeds terugkomt, leg je die vast in de linter.

Tests zijn ook code. Controleer of nieuwe code tests heeft. Controleer ook of de tests daadwerkelijk het juiste testen — veel tests slagen zelfs als de code kapot is, omdat ze het verkeerde controleren.

Reageer op elke opmerking — al is het maar met een duim-omhoogemoji. Maak bezwaar tegen suggesties waar je het niet mee eens bent (je hebt de code geschreven; misschien heb je extra context). Markeer opgeloste discussiedraden als opgelost. Werk de PR-beschrijving bij als de reikwijdte verandert.

Beoordeel binnen één werkdag. Bij verouderde PR’s gaat context verloren — de auteur is verdergegaan en de tak moet opnieuw op de juiste basis worden gezet. Grote PR’s die een week blijven liggen, worden altijd vreselijke samenvoegingen.

Met de suggestiefunctie van GitHub kan de auteur een oplossing met één klik accepteren. Dat is veel sneller dan in gewone tekst schrijven: ‘verander deze regel in X’.

Keur goed wanneer: de code correct is, de tests slagen, je de wijziging begrijpt en het veilig is om samen te voegen. Goedkeuren betekent dat je medeverantwoordelijkheid neemt voor het resultaat. Keur niet kritiekloos goed — als je het niet hebt gelezen, zeg dat dan.

Auteur: kleine, goed beschreven PR’s met schermafbeeldingen en tests. Beoordeel eerst zelf. Beoordelaar: constructieve feedback in de vorm van vragen. Maak onderscheid tussen een blokkade en een kleinigheid. Prijs het goede. Sla stijl over — laat tooling dat afhandelen. Beoordeel binnen een dag. Keur alleen goed als je de wijziging begrijpt. PR-sjablonen standaardiseren het proces. Reviews zijn samenwerking, geen poortwachterij.