Vijf tips voor de reviewer
In het eerste deel van mijn tweedelige reeks over kwalitatieve code reviews heb ik het gehad over wat je als ontwikkelaar kunt doen om te zorgen dat je pull requests overzichtelijk zijn en snel beoordeeld kunnen worden. In dit tweede deel draag ik een aantal tips aan die je als reviewer kunt gebruiken om goede feedback te geven en op deze manier bij te dragen aan een positieve cultuur binnen de organisatie.
Tip 1: Dek voldoende honken af
Veelal zie je in de praktijk dat een review inhoudt dat we alleen naar het minimale kijken omwille van de tijd. Hierbij kunnen we denken voor de hand liggende zaken, zoals onduidelijke naamgeving van variabelen, uitgecommente code of god-class functions. Kortom we kijken met name hoe de wijziging past in onze codebase. Echter missen we dan een belangrijk onderdeel namelijk een stukje context. Hoe past de wijziging in het totaal plaatje?
Een betere manier van reviewen is dus ook om te kijken hoe de wijziging past in de context van het systeem. Hierbij kun je denken aan aspecten als: “Zijn alle belangrijke business rules voldoende getest”, “Begrijp ik wel daadwerkelijk de gedachtegang van mijn collega?” en “Zijn er onderdelen van de code die efficiënter kunnen worden geschreven.”
Tip 2: Empathie is je vriend
De ondertoon die jij als reviewer aanhoud is van cruciaal belang. Reviews met een harde toon of stellige mening leiden al gauw tot het gevoel dat je niets meer wil bijdragen. Een professionele en positieve ondertoon zorgt voor veel meer betrokkenheid. Een goeie reviewer stelt dan ook open vragen en draagt suggesties aan voor eventuele verbeteringen zonder te impliceren dat er geen andere mogelijkheden zijn. Een nog briljanter persoon daarentegen onderkent ook het feit dat een collega tijd en moeite in zijn code geeft gestopt en toont een stukje begrip hiervoor.
Tip 3: Druk niet zomaar op Approved
Na het reviewen van de code druk je wel of niet op approved. Een review zonder commentaren en een snelle druk op de knop is eigenlijk zeer oncollegiaal. Je miskent als het ware de effort van een collega die hij/zij in een wijziging heeft gestopt. Een betere manier is om minimaal één vraag te stellen te stellen, waarbij je duidelijk maakt of het in jouw ogen gaat om een showstopper of hem een compliment geeft voor zijn inspanningen. Bijvoorbeeld voor een creatieve oplossing voor een bepaald probleem. Daarbij is het verder belangrijk om strict te zijn bij good coding practices, maar ook voldoende flexibel te zijn als een commentaar bijvoorbeeld kan worden opgelost in een andere PBI.
Tip 4: Ga voor face-to-face
Het is altijd goed om met behulp van een tool code reviews op afstand mogelijk te maken. In een tool heb je duidelijk overzicht welke vragen/commentaren er nog zijn, maar misinterpretatie ligt ook op de loer. Het kan ervoor zorgen dat jij en je collega een lange uitwisseling krijgen. Wanneer dit dreigt te gebeuren, kun je dan ook beter voor een face-to-face sessie met elkaar gaan.
Door proactief contact te zoeken met je collega kun je snel sparren met elkaar over vragen en/of commentaren. Dit bespaart een hoop ergernis, misverstanden en gekrenkte gevoelens.
Tip 5: Ga niet zitten muggenziften
Onder muggenziften kunnen we denken aan commentaren over kleine stukjes code die hadden kunnen worden samengevoegd, variabelen die niet “correct” zijn gedeclareerd, unittesten die niet volgens een bepaalde structuur zijn opgebouwd of brackets op dezelfde regel.
Reviewers kunnen dit soort commentaren onderkennen door aan te geven dat het geen showstoppers zijn en zoeken deze ook weinig mogelijk op. Teveel van dit soort muggenzifterij kan leiden tot frustratie en disharmonie binnen het team.
Een andere wijze om hiermee om te gaan is dat veel van dit soort commentaren vaak een rode vlag is voor een gebrek aan goede tooling en/of codeerstandaardafspraken. Zulke indicaties dienen dan ook buiten het reviewproces te worden opgelost door bijvoorbeeld een Code Linter te gebruiken, waarin alle afspraken van het team omtrent standaards zijn gedefinieerd. Voorbeelden van tools die hiervoor gebruikt kunnen worden, zijn Sonarqube of EditorConfig.
Conclusie
In conclusie.. Een gezond reviewproces wordt binnen de organisatie gefaciliteerd wanneer alle leden van het team hun verantwoordelijkheid nemen, zij het als auteur of reviewer. Gezamenlijk kun je een prettige interactie creëren door duidelijk te communiceren over de inhoud van de code, open te staan voor kritiek en constructief feedback te geven.
Gideon Kuijpers – Software Developer
