Code review: waarom je als eigenaar van een website of app er een nodig hebt

Je hebt een website, een webshop of een kleine app. Iemand heeft de code geschreven: een opdrachtnemer, een vriend, een bureau dat inmiddels verder is gegaan, of jijzelf na een paar weekenden tutorials. Het werkt, meestal. Maar je kunt niet zien of het stevig in elkaar zit of met plakband bij elkaar wordt gehouden. Een code review is een tweede blik van iemand die de code niet heeft geschreven, en die beantwoordt die vraag voordat een klein probleem een duur probleem wordt.

Wanneer een review de moeite waard is

• Voordat je betaalt voor opgeleverd werk. Een review laat zien of de code die je hebt gekregen degelijk is of vol shortcuts zit.
• Als je een project overneemt. Overgenomen code zonder documentatie is een black box totdat iemand hem uitlegt.
• Als er steeds iets kapotgaat. Een formulier dat soms niet werkt, een trage pagina, een fout die na elke fix terugkomt.
• Voor een lancering of een grote actie, wanneer een bug echt geld kost.
• Als je zelf code schrijft en wilt leren wat je beter kunt doen.

Wat een review vindt

Een reviewer leest de code regel voor regel en zoekt naar:

• Bugs: logica die in bepaalde gevallen faalt, zoals een lege winkelwagen, een datum aan het eind van de maand of een naam met een apostrof.
• Riskante plekken: wachtwoorden die in de code staan, invoer van gebruikers die zonder controle wordt gebruikt, foutmeldingen die te veel prijsgeven.
• Zwakke plekken: code die nu werkt maar breekt als het verkeer groeit of een library wordt bijgewerkt.
• Leesbaarheid: onduidelijke namen, lange functies en herhaalde code die elke toekomstige wijziging trager en duurder maken.

Problemen worden gesorteerd op belang, zodat je weet wat je eerst oplost en wat kan wachten.

Wat een review niet doet

Een review leest en verklaart code; hij voert die niet uit op je server en test je live site niet. Het is geen volledige beveiligingsaudit en geen loadtest. Zie de voorgestelde fixes als voorstellen: wie het project onderhoudt, moet elke fix testen voordat hij live gaat.

Zo kies je wat je instuurt

Een hele site is zelden nodig. Kies de delen die het meest tellen:

• Waar geld beweegt: afrekenen, betalingen, prijzen en kortingen.
• Waar gebruikers iets intypen: registratie-, inlog-, contact- en zoekformulieren.
• Waar het probleem zit: het bestand of de functie achter de fout die je ziet.

Een paar honderd regels van de juiste plek zeggen meer dan duizenden regels van alles.

Zo bereid je de code voor

• Haal geheimen weg. Vervang wachtwoorden, API-sleutels en klantgegevens door plaatshouders zoals PASSWORD_HERE.
• Noem de taal en versie, bijvoorbeeld PHP 8 of JavaScript met React.
• Beschrijf wat de code moet doen in een of twee eenvoudige zinnen.
• Kopieer de exacte foutmelding, als die er is, volledig.
• Zeg waar de nadruk op moet liggen: de bug, snelheid, leesbaarheid of riskante plekken.

Zo gebruik je het resultaat

Deel de review met wie de code onderhoudt en spreek de volgorde van de fixes af, te beginnen met de kritieke. Ben je zelf niet technisch, dan helpt de samenvatting in gewone taal je om de juiste vragen te stellen en de antwoorden te beoordelen.

Kort samengevat

Een code review is een onafhankelijke blik die bugs, riskante plekken en zwakke plekken vindt voordat je klanten dat doen. Wil je er een, bestel dan een code review: je plakt maximaal 100, 400 of 1.000 regels, beschrijft wat er misgaat en krijgt een schriftelijke uitleg van wat de code doet, een lijst met problemen gesorteerd op belang en verbeterde fragmenten om in je eigen project te testen. De betaling wordt pas vrijgegeven nadat je het werk hebt goedgekeurd.