Tag pull requests
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.
De edele kunst van het pull request
Veel ontwikkelaars zien code reviews als een hinderlijke onderbreking van hun werkzaamheden. Maar het goed kunnen beoordelen van een codewijziging is essentieel om de kwaliteit van een codebase op peil te houden. Gelukkig hoeft dit proces niet pijnlijk te zijn. Aan het eind van deze sessie weet je welke vragen je moet stellen voor een geslaagde code review – en hoe je deze informatie zo effectief mogelijk overbrengt in je PR.
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.
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.
Betere documentatie door PR-templates
Elk pull request biedt een gelegenheid om documentatie te schrijven. Toen ik dat punt een tijd geleden inbracht tijdens het tweewekelijkse Alignment-overleg van mijn team, viel mij tot mijn verbazing een hoop instemmend geknik ten deel. Hoe plezierig dat ook was, eerlijk gezegd verwachtte ik niet per se dat mijn pleidooi veel navolg zou vinden. Programmeurs en documentatie is en blijft nu eenmaal een moeilijk huwelijk. Maar mijn team verraste me positief.
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.