Onze cloud best practices voor het reviewen van pull requests

Een pull requests heeft een Developer en een Reviewer nodig. Idealiter dus een 4-ogen principe. Hierbij onze cloud best practices op een rijtje!

3
 min read  |  
18/8/2022
 |  
Business critical applications

Ja, het is zover. Je hebt keihard gewerkt om alle features waar je team zich aan het begin van de sprint aan gecommitteerd heeft af te krijgen. Met je team. Dus dat betekent automatisch ook dat iemand anders dan jijzelf de review doet en jouw code of wijziging checkt. Wat zijn onze cloud best practices voor het reviewen van pull requests? We nemen je mee door de voor sommigen nog ‘hidden feature’ in Azure DevOps en geven tips voor zowel de Developer als de Reviewer en we sluiten af met onze gouden tip.

Pull requests tips voor de Developer

Maak het jezelf en je team makkelijk door op een eenduidige manier te werken. Gebruik tooling in je eigen voordeel en maak afspraken over de kwaliteitseisen die je stelt. Niet alleen aan je code, maar ook aan je werkproces.

  • Keep it Simple! Kleine PR's (pull requests) zijn voor een reviewer eenvoudig en snel te reviewen, waardoor de feedbackloop snel en kort is en jij weer door kunt met het verwerken van de review comments. Of door met de volgende taak natuurlijk!  
  • Koppel niet meer dan 1 taak aan je pull request en beperk de wijzigingen in het PR tot de wijziging die voor die taak benodigd is.
  • Omschrijf duidelijk wat de wijziging van je PR inhoudt, zodat het voor de reviewer duidelijk is wat de context van de wijziging is.
  • Maak gebruik van tooling om zaken zoals coding-standaarden automatisch te checken / af te kunnen strepen.
  • Vraag om een "second opinion" van een tweede reviewer wanneer jij en de reviewer het ergens niet over eens zijn.
  • Wanneer je review comments verwerkt: zet bij elke comment een korte opmerking waaruit blijkt dat je het aangepast hebt. Zet de comment niet op "Resolved" maar laat dit over aan de reviewer. Dit zorgt ervoor dat de reviewer eenvoudig kan zien welke comments opgelost zijn en welke niet.
  • Maak automatisch een build van de code in je PR om te voorkomen dat de build breekt nadat jouw wijzigingen goedgekeurd zijn.

Geloof ons. Het maakt je leven als Developer een stuk makkelijk. Je hebt overzicht, waarborgt de snelheid en kwaliteit. En je maakt het een gezamenlijk resultaat.

Pull requests tips voor de Reviewer

Ben je al bekend met het 4-ogen principe? We ‘hameren’ er hem gewoon maar weer in hoor. Joost-Jan schreef er eerder al over en ook Anton bespreekt het in de Golden Path videoreeks. Moraal van het verhaal? Samenwerking is key! Lees meer op TeamValue - The Golden Path.

  • Check of de code in het PR voldoet aan de generieke architectuur principes en/of standaarden die jullie team hanteert.  
  • Doe daarnaast ook even een stapje achteruit en kijk of de wijzigingen in het PR passen in het grotere plaatje van het systeem waar de code onderdeel van is.
  • Check daarnaast of de code voldoet aan de specifieke acceptatiecriteria die bij de taak en/of het Product Backlog Item die aan het PR gekoppeld zijn.
  • Gebruik de ingebouwde feature van Azure DevOps om ‘een vinkje te zetten’ voor elke file die je gereviewed hebt. Hierdoor zie je na een update van het PR in een oogopslag wat je opnieuw moet reviewen. Je leest er op de site van Microsoft nog veel meer over. Review and comment on pull requests - Azure Repos | Microsoft Docs

Conclusie: een Developer maakt de code om de functionaliteit zoals die beschreven is in de user story te realiseren en maakt een pull request. Een mede-Developer voert een peer review uit waardoor het 4-ogen principe wordt gewaarborgd. Laatstgenoemde keurt het pull request na het afronden van de review en het verwerken van het eventuele review commentaar goed.

Onze gouden tip die je verder naar The Golden Path leidt

En dan de gouden tip! Het (peer) review proces in een team is super belangrijk! Maak daarom de afspraak in je team dat wanneer de build breekt en/of een bug die tijdens een review gezien had moeten worden, de reviewer hiervoor verantwoordelijk is. Wordt er iets gemist? Dan moet de reviewer trakteren! Let maar eens op hoe serieus de review taak na het maken van deze afspraak genomen wordt.. ;-) Bijkomend voordeel als het dan wel een keertje misgaat: iedereen leert ervan en er is bijvoorbeeld lekker taart op kantoor. Liever niet al te dik worden van teveel traktaties? Volg dan bovenstaande tips. Moet jij eens opletten hoe snel jullie team de waarde inziet van jullie eigen gouden pad.  

Meer lezen van onze cloud collega’s? > TeamValue - Blog

Download onze cheat sheet BizDevOps

We combineren data en toekomstgerichtheid met intuïtie en een blijvende gedragsverandering. Hoe? We schreven de eerste stappen voor je uit in onze cheat sheet BizDevOps. Download ‘m nu gratis en start vandaag nog met jouw digitale transformatie.

Meer informatie over deze blog? Kom in contact met de schrijver(s).
Joost-Jan Huls
Meld je aan voor de nieuwsbrief!
NU AANMELDEN