Een code review is de stap waarin een andere ontwikkelaar een voorgestelde wijziging leest voordat die deel wordt van het live product. De maker legt uit wat hij gedaan heeft, een reviewer leest het nauwkeurig, en samen vangen ze bugs, sporen ze onduidelijke stukken op en bevestigen ze dat het aan de norm van het team voldoet.
Het werkt zoals een tweede persoon die een belangrijke brief nakijkt voordat je hem verstuurt. Je hebt zo lang naar je eigen tekst gestaard dat je de typefout in de eerste regel niet meer ziet. Een verse lezer pikt hem er in seconden uit. In software gebeurt deze review meestal op een pull request, waar de voorgestelde wijziging naast de originele code staat en de reviewer regel voor regel commentaar kan geven. Behalve bugs vangen verspreidt het ook kennis over het team en houdt het het werk stilletjes dichter bij clean code.
Een goede review is een gesprek, geen poortje. Vragen en suggesties gaan beide kanten op, en het doel is een beter resultaat in plaats van een geslaagd-of-gezakt oordeel.
Een review nuttig houden is een vak apart. Kleine wijzigingen worden zorgvuldig gelezen, maar een pull request van 2.000 regels krijgt een vermoeide duim omhoog en dan glippen echte bugs erdoorheen. Sterke teams houden elke wijziging daarom klein, leggen in hun commentaar uit waaróm iets beter kan, en scheiden een blokkerend probleem van een persoonlijke voorkeur. Een review die over tabspaties zeurt maar een kapotte randsituatie mist, heeft op het verkeerde gemikt.
Bij TopDevs wordt elke wijziging door een tweede ontwikkelaar gereviewd voordat hij live gaat, zodat het product van een klant stabiel blijft en niemands blinde vlek in productie terechtkomt.
