Reviewen — wat is het, hoe werkt code review en PR-controle

Wat is code review

Code review — is het systematisch controleren van code door collega's vóór integratie. In de context van Git betekent dit: de ontwikkelaar maakt een pull request met wijzigingen, wijst reviewers aan, en zij bestuderen de diff, laten opmerkingen achter en geven een oordeel. De reviewer kan wijzigingen verzoeken (Request Changes), de PR goedkeuren (Approve) of een algemene opmerking plaatsen.

Code review heeft vijf doelen: verbetering van de codekwaliteit (detecteren van defecten voordat ze in productie komen), verspreiding van kennis (de reviewer leert nieuwe benaderingen kennen, de auteur ontvangt feedback), naleving van standaarden (controle op conformiteit met code style en architectuurbeslissingen), vermindering van de bus factor (code wordt niet door één ontwikkelaar gekend) en het opbouwen van een cultuur van verantwoordelijkheid (de auteur schrijft nauwkeuriger, wetende dat de code wordt gecontroleerd).

Het tegenovergestelde van code review is blind commit: de ontwikkelaar duwt wijzigingen naar de gemeenschappelijke tak zonder review. Deze aanpak is alleen toegestaan in projecten met één gebruiker of voor dringende hotfixes met een review achteraf. In professionele teamontwikkeling is code review een verplichte fase voor elke wijziging, inclusief documentatie- en configuratieaanpassingen.

Wat controleren in code review

Code review moet systematisch zijn, niet chaotisch. Ervaren reviewers controleren code in een bepaalde volgorde: eerst architectuur en logica, dan tests, vervolgens beveiliging en prestaties, en tot slot — stijl en naamgeving. Deze volgorde garandeert dat kritieke problemen worden opgemerkt voordat de reviewer moe wordt.

Architectuur en logica: lost de code het probleem op, zijn er overbodige abstracties, worden de SOLID- en DRY-principes nageleefd. Complexe code die moeilijk te begrijpen is bij eerste lezing — een signaal dat refactoring nodig is. De reviewer moet ervoor zorgen dat de code precies doet wat in de taak is gespecificeerd en geen neveneffecten heeft buiten zijn verantwoordelijkheidsgebied.

Tests: dekken de nieuwe tests alle scenario's — positieve, negatieve, randgevallen. Slagen bestaande tests na de wijzigingen. Zijn er flaky-tests die onstabiel falen. Beveiliging: afwezigheid van SQL-injecties, XSS, lekken van gevoelige gegevens via logs of API-antwoorden. Prestaties: efficiëntie van algoritmen, overbodige databasequery's, resourcelekken.

• Architectuur — juistheid van de oplossing, naleving van SOLID, geen over-engineering.
• Logica — afhandeling van alle scenario's, inclusief fouten en randgevallen.
• Tests — dekking van nieuwe wijzigingen, geen kapotte oude tests.
• Beveiliging — injecties, XSS, CSRF, datalekken via logs.
• Prestaties — complexiteit van algoritmen, N+1-query's, geheugenlekken.

Omvang review: waarom 400 regels het maximum is

Beperking van de PR-omvang — de belangrijkste metric voor de effectiviteit van code review. Onderzoek van Cisco (2015) en latere experimenten van SmartBear en Google toonden aan: bij een reviewomvang van meer dan 400 regels daalt het vermogen van de reviewer om defecten te vinden drastisch. Als een PR meer dan 400 regels overschrijdt, worden fouten ontdekt met een waarschijnlijkheid die niet hoger is dan toeval.

Optimale omvang: 200-400 regels per PR. Deze omvang kan door de reviewer in 30-60 minuten worden gecontroleerd, met behoud van concentratie. Google raadt niet meer dan 200 regels per reviewronde met volledige concentratie aan. Als er meer wijzigingen zijn — moet de taak worden opgesplitst in meerdere opeenvolgende PR's, die elk een logisch afgeronde wijziging introduceren.

Reviewtijd: binnen 24 uur na het maken van de PR. Als de review meerdere dagen duurt, gaat de context van de taak verloren en moet de auteur tijd besteden aan het herstellen van de context bij het beantwoorden van opmerkingen. Teams met een hoge code review-cultuur stellen SLA's in voor review: bijvoorbeeld 4 uur voor kritieke wijzigingen en 24 uur voor gewone.

Hoe schrijf je correcte reviewopmerkingen

De toon van opmerkingen — is cruciaal voor de effectiviteit van code review. Een opmerking "Dit is onjuist" roept een defensieve reactie op en geeft de auteur geen nuttige informatie. De beste formulering is een vraag-suggestie: "Wat vind je van deze aanpak?", "Hier kan een NPE optreden als user == nil. Misschien een guard toevoegen?". Vragen oefenen minder druk uit en stimuleren discussie.

De structuur van een goede opmerking bevat drie delen: wat er mis is, waarom het een probleem is en hoe het te corrigeren. Voorbeeld: "In deze lus wordt O(n²) gebruikt vanwege de geneste contains, wat kan vertragen bij 10k+ records. Probeer te vervangen door Set voor O(1) zoeken". Een dergelijke formulering geeft tegelijkertijd het probleem aan, verklaart het belang ervan en biedt een oplossing — de auteur hoeft niet te raden.

GitHub en GitLab ondersteunen suggestions — ingebouwde voorstellen voor codewijzigingen. De reviewer kan schrijven: "```suggestion Filter lege regels vóór verwerking```" — en de auteur past de wijziging met één klik toe. Dit versnelt kleine correcties en vermindert het aantal reviewrondes. Voor grote correcties is het beter een algemene opmerking te schrijven dan grote blokken in suggestion te plaatsen.

# Sjabloon voor goede code review-opmerking

# SLECHT: „Dit code is onjuist“
# GOED: „We kunnen gegevens verliezen bij lege response.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# GitHub suggestie syntax:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Code review workflow in het team

Een effectieve review-workflow is gebaseerd op vier fasen. Eerste — de auteur bereidt de PR voor: schrijft een begrijpelijke naam (bijv. "feat: add password reset screen"), voegt een beschrijving van wijzigingen, links naar de taak in de tracker en testinstructies toe. Tweede — de auteur wijst reviewers aan via auto-assign (op basis van CODEOWNERS) of handmatig.

Derde fase — de reviewer controleert de code en laat opmerkingen achter. Vierde — de auteur voert correcties uit, beantwoordt opmerkingen en vraagt om hernieuwde review. De cyclus herhaalt zich tot goedkeuring is verkregen. Na goedkeuring voert de author de merge uit (of de bot voert de merge uit). Automatisering via Mergify of GitHub Auto-merge versnelt de laatste fase.

Een belangrijk onderdeel van de workflow is beheer van verouderde PR's. Als een PR langer dan 3 dagen zonder review blijft, raakt het proces geblokkeerd. Oplossingen: rotatie van reviewers (als de aangewezen reviewer niet beschikbaar is), meldingen via Slack/Teams, tijdslimiet voor review (SLA). In sommige teams wordt een PR zonder review langer dan 7 dagen automatisch gesloten en maakt de auteur een nieuwe na synchronisatie met main.

• PR maken — begrijpelijke naam, beschrijving, links naar taak, screenshots bij UI-wijzigingen.
• Aanwijzen — auto-assign via CODEOWNERS of handmatige selectie van 1-2 reviewers.
• Review — controleren in volgorde: architectuur → logica → tests → beveiliging → stijl.
• Correcties — auteur beantwoordt alle opmerkingen, lost blocking issues op, vraagt om re-review.
• Merge — na goedkeuring en groene CI voert auteur of bot de samenvoeging uit.

Typische fouten in code review

Eerste fout — oppervlakkige review. De reviewer bekijkt de diff vluchtig, zonder in de logica te duiken, en drukt op Approve. Oorzaken: grote PR, deadline, vermoeidheid. Gevolgen: bugs komen in productie. Oplossing: als je geen tijd hebt voor kwalitatieve review — schrijf eerlijk "Ik kan vandaag niet controleren, verplaats naar morgen" in plaats van een formele goedkeuring.

Tweede fout — overmatige kritiek (nitpicking). De reviewer laat tientallen opmerkingen achter over opmaakstijl, variabelenamen, triviale details. Dit demotiveert de auteur en rekt de review. Oplossing: StyleGuide en linters moeten de stijl automatisch controleren. De mens in de review controleert logica, architectuur en beveiliging.

Derde fout — review zonder vragen. Als de reviewer alleen Request Changes en Approve plaatst, maar geen vragen stelt, mist hij de kans om iets nieuws te leren. De beste indicator van een gezonde code review is de aanwezigheid van discussies waarin beide partijen iets nieuws leren. Als de review een monoloog is van een van de deelnemers — is het proces kapot.

• Oppervlakkige review — Approve zonder verdieping. Oplossing: niet reviewen als je geen tijd hebt.
• Nitpicking — kritiek op stijl die door linter wordt gecontroleerd. Oplossing: automatiseer style checks.
• Persoonlijke perceptie — "ik zou het anders schrijven". Oplossing: code moet werken, niet leuk zijn voor de reviewer.
• Rekken — review langer dan 24 uur. Oplossing: SLA voor review, escalatie bij overtreding.
• Context negeren — code-review zonder begrip van de taak. Oplossing: lees de PR-beschrijving vóór de diff.