Tag pair programming
Teveel tegelijk
“We zijn met teveel dingen tegelijk bezig,” constateert een ontwikkelaar tijdens de Retrospective. Die is met dit bezig, die met dat; hij met zus en zij met zo. Er is geen eenheid, iedereen werkt op zijn eigen eiland. – Het is een terugkerend thema. Waar ligt dat aan?
Enkele gedachten over code reviews
De praktijk van pull requests is een vertragingstactiek. Dat is een teken dat er niet op vertrouwd kan worden dat de kwaliteit van nieuwe code structureel aan de gewenste kwaliteitsstandaarden voldoet. Zo bezien, zijn PR’s een pleister op een wond die veel intensievere behandeling behoeft.
Waarom wil Carl niet pairen?
Scenario: Alice en Bob bespreken hun positieve ervaringen met pair programming in de Sprint Retrospective. Ze stellen voor het vaker te doen. Carl is defensief. “Ik vind het niet fijn als een ontwikkelaar op mijn vingers meekijkt hoe ik code typ.” – Wat is hier aan de hand?
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 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.
Wij van TDD-eend...
Het is waar: uit het feit dat er tests zijn, valt niet te concluderen dat het systeem functioneert zoals verwacht - preciezer: zoals de eindgebruiker verwacht. Er valt hooguit uit te concluderen dat het systeem functioneert zoals de schrijver van de tests verwachtte. En als de schrijver van de tests tevens de ontwikkelaar van de code is, dan vormen de tests niet meer dan een verslaglegging van de aannames die de ontwikkelaar had tijdens de implementatie. En tóch geloof ik dat TDD het probleem van mijn collega - mijn feature voldoet niet aan de (impliciete?) requirements - had kunnen verhelpen.
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.