cultuur.
De codereviewer: een typologische studie
Een deel van het dagelijks werk van onze developers is de fameuze code-review. Het is deel van de zogenaamde ‘pull request’: hét moment waarop de nieuw gemaakte code samengevoegd gaat worden met de rest van het project. Een stap in ons ontwikkelproces waarbij developers elkaars code controleren op netheid, juistheid en veiligheid. Het is daarmee een belangrijk deel van de borging van de kwaliteit van gemaakte software.
In het uitvoeren van code-reviews zijn we als Whyellow zeker niet uniek. (dat hopen we in ieder geval). Ieder zichzelf respecterende softwarebouwer hanteert enige vorm van code-review, maar een echt fatsoenlijke controle blijkt vaak lastiger dan op het eerste gezicht lijkt. Eigenlijk is dit voor niet-developers het makkelijkst te vergelijken met het nakijken van een stuk geschreven tekst. Spelling en grammatica zijn simpele regels die makkelijk gecontroleerd kunnen worden, de juiste opbouw van een document wordt al lastiger en schrijfstijl kan heel persoonlijk zijn en dus onderhevig aan meningen. De code van software zou je dan ook kunnen beschouwen als een boek dat geschreven is door meerdere auteurs. Uiteindelijk mag dat in het resultaat natuurlijk niet zichtbaar zijn.
Een nuttige en bovendien vermakelijke manier om te bepalen wat eigenlijk een goede code-reviewer is, is een beschouwing van types in de wereld van de code-reviewers. Waarschuwing: zelf-herkenning en confrontatie met valkuilen zijn hierbij niet uitgesloten.
Type 1: De Haastige Harry
Code reviews kosten tijd…kostbare tijd. De echte Haastige Harry maakt er een kunst van om deze kostbare tijd terug te winnen. Honderd regels code goedkeuren binnen vijf minuten is geen enkel probleem. De klant wacht immers!
Haastige Harry neemt code-reviews niet serieus genoeg, maar valt gelukkig snel door de mand. Dit type code-reviewer leggen wij bij Whyellow het liefst onder de pijnbank.
Type 2: De onderdaan
De onderdaan heeft óf een hoge pet op van zijn collega’s, óf een lage dunk van zichzelf, óf beide. Elke geplaatste opmerking zou er één teveel kunnen zijn, dus wordt nauwkeurig overwogen wat er gezegd wordt. De onderdaan plaatst commentaar vooral om te laten zien dat hij geen Haastige Harry is, maar kan belangrijke opmerkingen weglaten.
De cultuur zorgt er gelukkig al voor dat dit type in Nederland niet veel voorkomt. Door iedereen ruimte te geven en elke opmerking serieus te nemen (ook junioren kunnen leren door code van een senior te reviewen) laten wij developers ook nog eens van elkaar leren. Hierdoor proberen we zoveel mogelijk een situatie te creëren waarbij er geen digitale bladeren voor de mond worden genomen.
Type 3: De punctualist (aka punt-komma-pieper)
Dit type is ook zeker bekend voor mensen die geschreven tekst laten nalezen. Dit is namelijk het type dat alleen spel- en grammaticafouten detecteert. In het geval van de developer gaat het daarbij over het gebruik van punt-komma’s, hoofdletters, underscores en (ook een leuke voor geschreven tekst) incorrect spatiegebruik.
De punctualist moet echter vrezen voor zijn baan. In moderne software hebben we deze namelijk….geautomatiseerd. Onze software corrigeert met behulp van zogenaamde linters (developersvariant van een spellingchecker) en dergelijke, die de code controleren op onjuistheden.
Type 4: De dinosaurus
Er bestond een tijd dat variabelen allemaal werden afgekort. Er bestond een tijd zonder dependency injection (maak je geen zorgen als je niet weet wat dat is). Er bestond een tijd dat alles anders was…de tijd van de dinosaurus. De dinosaurus van de code-reviews maakt opmerkingen over de code omdat deze niet meer door de dino wordt begrepen. De dinosaurus is vergeten bij de tijd te blijven.
Het uitgangspunt is: zorg dat je bij de tijd blijft. Gelukkig hebben we bij Whyellow geen dinosaurussen – althans…degene die het meest in de buurt komt, is tevens de auteur van dit stuk.
Type 5: De quiz-master
De echte quiz-master is een developer die geen opmerkingen plaatst bij een code-review, maar slechts vragen. “Waarom doe je dit zo?”, “Wat betekent dit?”, “Kan dit niet anders?”
Eerlijkheid gebiedt te zeggen dat ik dit type nog nooit heb ontmoet. Eigenlijk mist de gemiddelde code-reviewer eerder een stukje quiz-master. Bij twijfel is het belangrijk om in een review ook een vraag te durven stellen. Het reviewen van code is net zo goed een leerproces als een kwaliteitscontrole.
Type 6: De vlijtige criticus
De criticus is bij iedere developer bekend. Dit is die ene persoon waarvan je weet dat als hij of zij de code nakijkt, je er niet met één vergeten puntkomma afkomt. De angstgegner onder met name de junioren, maar heel nuttig. De enige valkuil: tijd! Als de criticus een echte vlijtige criticus is én zin heeft, wordt de hele code in je review opnieuw geschreven, maar dat is natuurlijk niet het idee van een review!
Geachte vlijtige criticus: Zorg dat de maker leert van de review en ook zelf aanpassingen doorvoert. Geef suggesties en speel af en toe quiz-master!
Type 7: De positivo
Vraag een developer of hij ooit positief commentaar op een code-review heeft gekregen en je zal een glazige, vragende blik terug ontvangen. De code-review wordt (en dat is natuurlijk eigenlijk het doel) gebruikt voor het aangeven van fouten en verbeteringen. Hoe verfrissend is het echter als er een positivo een opmerking plaatst bij een strakke, nette, weldoordachte oplossing. “Wat een fraai stukje code heb je daar geproduceerd vriend!”
De all-rounder
Uiteraard is het idee van een code-review dat de kwaliteit van de code top blijft én dat developers van elkaar kunnen leren. Hoe je code ook reviewt, het dient netjes te gebeuren, op syntax, semantiek, correctheid, etc. gecontroleerd te worden én het moet niet de spuigaten uitlopen qua tijdsinvestering (automatiseren!). Online zijn er voldoende ‘beste practices’ te vinden voor goede code-reviews.
Hierbij is belangrijk dat code-reviews door iedereen worden uitgevoerd. Enerzijds omdat het niet altijd leuk is om te doen (afwisseling zorgt voor betere reviews!), anderzijds omdat het de mogelijkheid geeft om van elkaar te leren.
De tip: Zorg ervoor dat code-reviews niet slechts een formaliteit zijn! Zorg ervoor dat code-reviews en het bijbehorende proces bewust worden gedaan en zelf ook kritisch worden bekeken!
Deze blog is geschreven door Joël de Jong, Software architect bij Whyellow.
