Onze cloud best practices voor het reviewen van pull requests

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