The Big Power of Small Pull Requests: Hur de förbättrar recensioner och påskyndar utvecklingen

Jag har skrivit kod professionellt i mer än fem år nu. Under de första fyra åren brydde jag mig aldrig om storleken på mina pull-förfrågningar (PR). Men under det senaste året övergick jag från att skicka in massiva PR med tusentals rader av ändringar till att dela upp dem i mindre, mer hanterbara. Fördelarna med detta skifte har varit enorma, och i den här bloggen kommer jag att dela med mig av dessa fördelar.

Enligt GitHub är en pull-begäran:

En pull-begäran är ett förslag om att slå samman en uppsättning ändringar från en gren till en annan. I en pull-begäran kan samarbetspartner granska och diskutera den föreslagna uppsättningen ändringar innan de integrerar ändringarna i huvudkodbasen.

I huvudsak är en pull-begäran ett sätt att samarbeta; vi bör göra allt för att förbättra detta samarbete. En effektiv metod för att förbättra detta samarbete är att hålla PR små.

Det finns ingen universell definition för att skilja mellan en liten och en stor PR. Att enbart förlita sig på antalet ändrade rader är otillräckligt, eftersom autogenererad kod och tester kan öka antalet rader. När jag hänvisar till små PR i den här artikeln menar jag att dela upp en större PR i flera mindre, logiskt sammanhängande PR. Varje mindre PR bör vara fristående, sammanfogningsbar och distribuerbar.

Jag förespråkar inte artificiell uppdelning som att dela en PR i två, en som innehåller all kod och en annan med bara testerna, eftersom detta tillvägagångssätt inte ger några fördelar som jag delar nedan.

Effektiva recensioner:

Be en programmerare att granska 10 rader kod, han hittar 10 problem. Be honom göra 500 rader så säger han att det ser bra ut.

Även om det är humoristiskt bär detta citat på sanning. Alla är upptagna med sitt eget arbete, och när du ber någon att granska en PR, begär du i huvudsak deras tid. Att granska en PR kräver att granskaren byter sammanhang från sitt eget arbete, och om granskningen tar avsevärd tid kan det vara en utmaning för dem att återgå till sitt arbete, vilket potentiellt påverkar deras motivation och engagemang för granskningen.

Mindre PR, som bara tar cirka 20–30 minuter att granska, är mycket lättare att ta itu med jämfört med de som kan ta 2–3 timmar. Dessutom leder större PR ofta till förbiseenden eftersom vår uppmärksamhet bara kan hantera så mycket, och att hoppa mellan massor av förändringar i en enda PR kan vara förvirrande. Enligt min erfarenhet tenderar mindre PR:er att få bättre feedback och leda till mer meningsfulla designkonversationer.

Snabbare recensioner:

Vid det här laget funderar jag på att lägga till min PR i mitt testamente ifall det fortfarande är under granskning efter att jag är borta.

Längre PR kräver en betydande tidsåtgång från granskarna, vilket gör dem mindre benägna att få uppmärksamhet - särskilt om de inte är bundna till högeffektiva funktioner. Små PR granskas å andra sidan snabbt, eftersom de kräver mindre av granskarens tid och är mindre påträngande.

Denna hastighet av granskningar kan vara avgörande för att uppfylla projektdeadlines; Jag har sett projekt bli försenade eftersom seniora granskare inte kunde avsätta tid för massiva PR (även om detta kan hända med små PR, är risken i sig högre med stora).

Mindre omarbetning:

Att omarbeta en stor PR efter designförändringar är som att arrangera om solstolar på ett fartyg som du precis har byggt färdigt... och sedan sänka det.

Vi har alla upplevt situationer där någon inser under PR-granskning att en annan design skulle ha varit mer underhållbar och framtidssäker, och vi behöver spendera ytterligare tid på att omarbeta PR baserat på den nya designen (för att inte säga att de var helt ombord med den design som ursprungligen implementerades :p). Detta är väldigt naturligt eftersom saker och ting ibland blir tydligare när du ser dem skrivna i kod, och du börjar märka aspekter som du kanske har missat under designfasen.

Med stora PR kan detta vara en betydande fråga eftersom du måste omarbeta många element, men med mindre PR är det lättare att göra ändringar. Ännu viktigare är att det finns en lägre chans för omarbetning eftersom granskare är mer benägna att identifiera problem tidigt och ta itu med dem i de inledande PR, vilket gör att efterföljande PR kan baseras på de nya designerna.

Bättre testning:

Mindre PR gynnar dig också som författare till PR. De hjälper till att testa mindre förändringar stegvis snarare än att testa hela projektet på en gång. Att testa mindre ändringar resulterar i mer omfattande testning av varje komponent i systemet, vilket leder till färre produktionsbuggar. Detta gäller både automatiserade tester och manuella tester utförda av dig eller dedikerade QA-ingenjörer.

Dessutom minskar mindre PR:er sannolikheten för missade testfall, eftersom du kan fokusera på en begränsad omfattning snarare än hela systemet.

Skriva prov? Det låter som Future Mes problem.

Jag har sett utvecklare (inklusive mig själv tidigare) tveka att skriva automatiseringstester på grund av den upplevda tidsinvesteringen utan omedelbart, "synligt" värde för funktionen/produkten. Mindre PR minskar denna friktion genom att begränsa antalet tester som krävs och tiden som går åt till att skriva dem.

Enklare felsökning:

Oavsett hur noggrann din testning är, kommer produktionsbuggar att hända! Att kunna felsöka en bugg i produktionen är avgörande eftersom produktionsbuggar direkt påverkar användare, verksamheten eller båda. Med stora PR är förändringsytan också stor, vilket gör det tidskrävande och svårt att hitta grundorsaken till problemen. Å andra sidan innehåller mindre PR:er mindre kod och gör därför felsökningen mycket snabbare.

Att felsöka små ändringar är som att hitta ett stavfel; att felsöka stora förändringar är som att korrekturläsa ett uppslagsverk.

Fasad funktionsdistribution:

Sist men inte minst, mindre PR är också till hjälp för din produktchef och användare. Genom att använda små PR:er kan du kontinuerligt driva delar av systemet till produktion, vilket hjälper till att få tidig feedback från användare och möjliggör tidiga kurskorrigeringar vid behov.

Att hoppa över tidig feedback är som att laga en femrätters middag utan att smaka på något – du hoppas bara att det inte är en katastrof.

Fördelarna med små PR är många, och punkterna ovan är bland de mest effektfulla jag har upplevt personligen. Om du har stött på andra fördelar med små PR eller utmaningar med större som jag inte har täckt, kommentera gärna med dina insikter.

Jag hoppas att den här artikeln motiverar dig att anamma mindre PR. Om du redan är ombord hoppas jag att det förstärker värdet av denna praxis.

Tack för att du läser, tills nästa gång, fortsätt koda och var nyfiken!