code reviews
Erfenissen van waterval
Op het Najaarsevenement van TestNet betoogde ik dat testers een belangrijke rol hebben te spelen in het reviewen van code. Tijdens de voorbereiding van mijn presentatie realiseerde ik me dat mijn team, alle Agile ambities ten spijt, in zijn denken nog diep verankerd zit in het gedachtegoed van de watervalopvatting van softwareontwikkeling.
Nog enkele reflecties op pull requests
Onlangs hield ik een praatje op het werk over de edele kunst van het pull request. Het gesprek dat naar aanleiding daarvan ontstond, vond ik erg waardevol. Het geven van een goede presentatie werkt in bepaalde zin net als software ontwikkelen: je maakt een eerste versie, legt die voor aan een groep mensen, en gebruikt hun feedback om een betere tweede versie te ontwikkelen.
Drie vragen die elk pull request moet beantwoorden
Schrijvers van pull requests zijn over het algemeen helemaal niet zo goed in het overbrengen van alle informatie die een lezer nodig heeft om deze goed te kunnen beoordelen. Want de meeste schrijvers weten überhaupt nauwelijks welke informatie er nodig is om dat te kunnen doen. In mijn beleving moet een PR antwoord geven op drie vragen.
Mijn eerste code review
De tijd maakt alles kapot – maar nu ben ik nog jong genoeg om me mijn eerste code review te herinneren. Althans, ik herinner me een gevoel – want de inhoud van het pull request ben ik natuurlijk allang kwijt. Het gevoel laat zich denk ik het best omschrijven als een vorm van hulpeloosheid – gevolgd door ongemak.
De tester als code reviewer
Mijn team heeft onze tester onlangs tot verplichte reviewer gemaakt voor elk pull request (PR). Hij heeft een heel specifieke opdracht – drie, eigenlijk: 1. Ga na of het PR unit- of integratietests bevat. Zo nee, keur het PR dan af. 2. Ga na of je de unit- en/of integratietests kunt begrijpen. Zo nee, keur het PR dan af. 3. Ga op basis van de unit- en/of integratietests na of de code werkt zoals bedoeld. Zo nee, keur het PR dan af. Pas als aan alle drie voorwaarden is voldaan, is het PR klaar om naar de main branch te mergen.
Is pair programming minder efficiënt?
Mijn team worstelt een beetje met het vlot doorzetten van pull requests. Dus vertelde ik tijdens een borrel aan een collega uit een ander team van mijn voornemen vaker te pair programmen. Hij was geen fan.
Wel code reviews, geen pull requests
Tijdens een Sprint Retrospective zei ik: “Ik heb het gevoel dat het te lang duurt voordat onze pull requests (PR’s) worden gecodereviewd. Hebben andere mensen datzelfde idee?” Ja, ze hadden hetzelfde idee. We spraken af: als je merkt dat er niets met je PR gedaan wordt, trek dan iemand even aan de jas. Het is een oplossing die vooralsnog goed genoeg werkt. Maar hij laat een belangrijke oorzaak - misschien wel dé belangrijkste oorzaak - van het probleem in stand: het bestaan van PR’s überhaupt.
Pull requests als documentatie
Hoe vaak denk je na over de titel en omschrijving van je pull request? Als je een beetje op mij lijkt, dan is het antwoord: veel te weinig. Het goede nieuws is: je hoeft er niet over na te denken, want dat hebben de vriendelijke ontwikkelaars van Google al voor je gedaan. Onlangs las ik hun Code Review Developer Guide door, en vond daar een schat aan informatie.
Test-Driven Code Reviews
Door een alfabetisch toeval presenteert Azure DevOps elk pull request van mijn team in deze volgorde: eerst de front-end, dan de back-end - de API, de businesslogica, de datatoegang en het model - en ten slotte te tests. Onlangs stelde ik de vraag hoe je eigenlijk code reviewt - en waar je het best kunt beginnen bij zo’n beoordeling. Ik heb er een tijdje op zitten broeden, en ik denk dat ik eruit ben.
Hoe review je eigenlijk code?
Hoe lees je eigenlijk code? Waar begin je? En in welke volgorde loop je code door? - En zit er verschil tussen het lezen van code tijdens je programmeerwerk en tijdens een code review? Ik stelde mezelf onlangs die vragen, na in Felienne Hermans’ The Programmer’s Brain te hebben gelezen dat gevorderde programmeurs op een andere manier code lezen dan nieuwelingen.