𝗧𝗵𝗲 𝗥𝗲𝗮𝗹 𝗥𝗲𝗮𝘀𝗼𝗻 𝗬𝗼𝘂𝗿 𝗣𝗥𝘀 𝗚𝗲𝘁 𝗕𝗶𝗴
Ik werkte ooit bij een bedrijf dat uit gewoonte enorme pull requests verstuurde. Eén PR kon wekenlang open blijven staan. Het reviewen ervan vereiste dat je een heel subsysteem in je hoofd hield. Bugs stapelden zich op. Deadlines werden gemist. Uiteindelijk moesten we een groot deel van het systeem herbouwen omdat niemand het meer veilig kon aanpassen.
De engineers waren niet slecht. Ze waren slim en werkten hard. De PR's werden groot om een saaie reden.
Niemand had hen geleerd hoe ze het werk moesten opdelen.
We beschouwen grote PR's vaak als een disciplineprobleem. We zeggen: "Maak gewoon kleinere PR's." We doen alsof wilskracht het enige verschil is tussen 1.500 wijzigingen en 150 wijzigingen.
Het gaat niet om wilskracht. Het opdelen van groot werk in kleine, onafhankelijke stukjes is een vaardigheid. De meeste mensen leren dit nooit. Wanneer een ticket zegt "voeg facturering toe", voelt dat als één enkele taak. Het lastige is zien waar de ene PR eindigt en de volgende begint.
Ik verstuurde vroeger ook grote PR's. Ik dacht dat "klaar" betekende dat ik het hele probleem in één keer oploste en het ter review stuurde. Het duurde jaren voordat ik leerde dat kleiner beter is.
Kleine PR's veranderden alles voor mij:
- Reviewers vinden meer bugs. Een mens kan nadenken over 200 wijzigingen. Over 2.000 niet. Ze scannen het alleen maar en keuren het goed.
- Merges gaan sneller. PR's blijven niet meer in de wachtrij staan.
- Ik voelde me niet langer overweldigd. Ik concentreerde me op één onderdeel tegelijk.
- Ik werd een betere planner. Je moet de vorm van je werk begrijpen om het te kunnen opdelen.
Ik begon systemen te zien als Lego-steentjes. Het zijn kleine stukjes die in elkaar klikken. Zodra je de steentjes ziet, voelt het natuurlijk om het werk op te delen.
Mijn huidige team verstuurt kleine PR's. De resultaten zijn duidelijk:
- Onze gemiddelde merge-tijd is 1,5 dag.
- We vinden en fixen bugs snel omdat de wijzigingen leesbaar zijn.
- Onze leveringstermijnen zijn consistent.
Het opdelen van werk is een vaardigheid die je moet coachen. Je kunt grote PR's niet oplossen met een regel. Je lost ze op door mensen te leren de steentjes te zien.
AI maakt deze vaardigheid nog belangrijker.
In het verleden kostte het schrijven van 2.000 regels code veel moeite. Die frictie hield PR's kleiner. AI heeft die frictie weggenomen. Je kunt met één prompt enorme wijzigingen genereren.
De inspanning is niet verdwenen. Het is alleen verschoven naar de reviewer. De auteur betaalt niets, maar de reviewer betaalt de volle prijs.
Als omvang niet langer aangeeft hoeveel werk een auteur heeft verricht, zegt de omvang je weinig over het risico. Je moet zelf bepalen welke onderdelen je meest zorgvuldige aandacht verdienen.
Leer je team om de bouwstenen te zien. Het is de gewoonte met de grootste impact binnen engineering.
Hoe bepaalt jouw team welke PR's een grondige review nodig hebben en welke snel goedgekeurd kunnen worden?
Bron: https://dev.to/pixel-wraith/the-real-reason-your-prs-get-big-5cm3
Optionele leercommunity: https://t.me/GyaanSetuAi