En utvecklare öppnar en pull request som lägger till en rabattberäkning i en utcheckningstjänst. Testerna klarar och skillnaden är kort. En granskare godkänner den på två minuter med "LGTM". Tre månader senare behöver en lagkamrat ändra samma funktion och upptäcker att den blandar prisregler, avrundning och databasåtkomst på ett ställe. Ingen kan med säkerhet säga vad den är tillåten att göra.
Detta är ett illustrativt scenario, inte en dokumenterad incident. Det visar vad kodgranskning med kollegor kan producera när den fungerar som en lärandeaktivitet: en granskare som kan se en rimlig förändring, identifiera problemet som ännu inte är en bugg och förklara det på ett sätt som författaren kan agera utifrån.
Den här guiden är för projektledare och tekniska chefer. Den visar hur man utformar övningar i kodgranskning som bygger upp den färdigheten med flit, istället för att hoppas att granskare ska plocka upp den från kön. Den täcker prestationsproblemet, luckorna att diagnostisera, hur man strukturerar förberedelser och övning, ett fungerande exempel och hur man kontrollerar att färdigheten överförs till riktiga granskningar. Låt seniora ingenjörer validera varje fall, defekt och kriterium innan du använder det.
Vad är kodgranskningsövningar?
Kodgranskningsövningar är strukturerade övningsuppgifter där en utvecklare granskar en förberedd ändring, förklarar vad de hittat och varför det är viktigt, och får feedback på kvaliteten på den förklaringen. De skiljer sig från de granskningar som ditt team gör varje dag. Ändringen väljs i förväg, problemen med den är kända, och målet är att förbättra granskaren snarare än att leverera ändringen.
Snabb fakta
| Fråga | Kort svar |
|---|---|
| Vad är uppgiften? | Förklara granskningsresultaten och ge feedback som författaren kan agera utifrån. |
| Vad får du i poäng? | Resultatens noggrannhet och hur användbar förklaringen är. |
| Räcker det med att räkna defekter? | Nej. Recensioner handlar om mer än bara defekter, så en övning som bara belönar antalet fel tränar upp fel vana. |
| Vad är det kognitiva kravet? | Analysera och utvärdera en design och skapa sedan ett bättre förslag. |
| Vem bekräftar fallet? | En teknisk chef eller senior ingenjör som äger kodbasen. |
| Vad kan övningar inte åtgärda? | Granskningstid, oklart ägarskap och press att snabbt slås samman. |
| Hur vet du att det fungerade? | En ny, osynlig förändring som granskats mot överenskomna kriterier, plus en uppföljning av verkliga granskningar. |
1. Beskriv prestandaproblemet
Börja med uppgiften, i en mening: givet en förändring förklarar granskaren vad de hittat, varför det är viktigt och vad författaren kan göra åt det. "Förklarar" är det viktiga ordet. Att upptäcka ett problem är halva färdigheten. Att säga det så att en kollega med en annan åsikt kan förstå det, väga det och agera är den andra halvan.
Forskning om modern kodgranskning stöder att man ser bortom buggjakt. I en studie på Microsoft observerade, intervjuade och undersökte Bacchelli och Bird utvecklare och chefer. De fann att det fortfarande var den främsta motivationen för granskning att hitta defekter, men att granskningar handlade mindre om defekter än vad folk förväntade sig. De gav också andra fördelar, såsom kunskapsdelning, teammedvetenhet och alternativa lösningar, och forskarna beskrev kod- och förändringsförståelse som den viktigaste aspekten av granskning (Bacchelli och Bird, ICSE 2013Det är en studie av ett företags team, så använd det som en anledning att designa för förståelse, inte som ett betyg för dina egna.
Googles publicerade granskningsstandard pekar på samma sätt. Den säger att granskare bör godkänna en ändring när den definitivt förbättrar kodens allmänna tillstånd, även om den inte är perfekt, och den säger att granskning kan lära utvecklare något nytt, så kommentarer som hjälper någon att lära sig är välkomna (Googles tekniska praxisBåda källorna beskriver granskning som en plats där bedömningar utövas och förmedlas. Det är vad dina övningar bör öva på.
2. Diagnostisera inlärnings- och kontextuella luckor
Jämför uppgiften med vad ditt nuvarande program praktiserar och utvärderar.
- Använder nuvarande praxis den verkliga uppgiften? Om nya granskare lär sig genom att läsa en stilguide och sedan granska live pull requests, övar de på verkligt arbete utan någon säker plats att ha fel. Om bedömning är ett quiz om granskningsetikett, mäter det återkallelse av reglerna, inte förmågan att tillämpa dem på en förändring.
- Vad är det kognitiva kravet? I den reviderade Blooms taxonomi sker bedömningen av huruvida en design är sund och vägning av dess avvägningar på analys- och utvärderingsnivåerna, och förslag på en bättre struktur når skapandenivån. Om dina övningar bara frågar "vad gör den här koden?", stannar de vid förståelse. Vår guide till matcha läraktiviteter med Blooms taxonomi visar hur man matchar aktiviteten med nivån.
- Är det något annat än skicklighet som kommer i vägen? Kontrollera granskningstid, verktyg, ägarskap och teamnormer. Om granskare har fem minuter per pull request kommer ingen övning att ge en genomtänkt förklaring. Om författare tar varje kommentar som kritik kommer granskarna att mildra sina resultat tills de inte säger något. Rapportera dessa orsaker till de personer som kan åtgärda dem.
3. Förberedelser, övning och feedback inför designen
Ge varje steg ett separat jobb.
Förberedelse. Kontrollera vad granskare behöver innan de börjar: teamets granskningschecklista, de designprinciper som den bygger på och hur man läser en skillnad i era verktyg. Håll detta i egen takt och kort. En återkallelsekontroll bekräftar endast förutsättningarna och är inte ett bevis på att någon kan granska.
Öva. Använd förberedda ändringar med ett litet antal initierade problem av olika slag: en korrekthetsbugg, ett underhållsproblem som de blandade ansvarsområdena i det inledande exemplet, ett oklart namn eller saknat test, och lite kod som är okej. Be granskaren att skriva den kommentar de skulle lämna, rangordna problemen och ange vilken ytterligare information de skulle vilja ha. CodeRefinerys praktiska lektion visar formen: personer öppnar en pull request som innehåller ett litet stavfel och ett större misstag, och granskar den sedan som en kollega (CodeRefinery, Övning av kodgranskning). Bygg din egen kodbas så att konventionerna och avvägningarna är verkliga.
Återkoppling. Koppla det till de beslut som granskaren fattade. ”Du märkte avrundningsproblemet men din kommentar sa 'detta ser fel ut' utan att ange vilken inmatning som förstör det” är mer användbart än ”hittade 2 av 4”.
Liveinmatning eller asynkron granskning? Live-input ger mest värde när en fråga är tvetydig och granskare lär sig av att höra en senior ingenjör säga varför de skulle ta upp den, eller låta bli att göra det. Asynkron granskning räcker för att jämföra kommentarer med en kommenterad expertgranskning.
4. Arbeta igenom ett realistiskt exempel
Illustrativt. En teknisk chef bör validera fallet och svarskriterierna före användning.
Fallet. En ändring lägger till en rabattberäkning i en utcheckningstjänst. Den klarar sina tester. I en funktion tillämpar den procentuella och fasta rabatter, avrundar resultatet, skriver till databasen och skickar en händelse. Den har ett test, för en enda procentuell rabatt.
Uppgiften. Granskaren skriver ner de kommentarer de skulle lämna, rangordnar sina funderingar och säger vad de skulle behöva veta innan de godkänner.
Ett första försök. ”Ser bra ut, testet klarar det. Kanske man ska dela upp det?” Recensenten har lagt märke till något men har inte sagt vad, varför det är viktigt eller vad man ska göra. Författaren kan inte agera utifrån detta.
Feedback och försök igen. Handledaren frågar: vilken framtida förändring av den här funktionen riskerar att gå sönder? Vad skulle du be författaren att lägga till innan du godkänner? Vid det nya försöket efterfrågas en specifik kommentar till varje fråga, med anledning och ett förslag.
Ett starkare försök. "Funktionen tillämpar två typer av rabatter, avrundar, sparar och publicerar en händelse, så en ändring av avrundning kan ändra vad vi lagrar och vad vi publicerar samtidigt. Jag skulle be att prissättningsreglerna flyttas till en ren funktion som vi kan testa på egen hand. Det enskilda testet täcker endast en procentuell rabatt. Jag skulle be om en fast rabatt och en order som bringar totalen till noll. Jag är inte säker på om händelsen är avsedd att utlösas när totalen är noll, så jag skulle fråga författaren." Observera att denna kommentar namnger problemet, anger orsaken, ger ett konkret förslag och anger vad granskaren inte vet.
5. Bedöm kapacitet och planöverföring
Bevis på förmåga är prestation på en ny förändring som granskaren inte har sett. Poängsätt resultatens noggrannhet och förklaringens användbarhet. En enkel matris använder en skala från 0 till 2 per kriterium:
| Kriterium | Observerbara bevis |
|---|---|
| Uppgiftskörning | Hittar de relevanta problemen i förändringen och dokumenterar bevisen för var och en. |
| Resonemang | Förklarar varför varje fråga är viktig, erbjuder ett alternativ och säger vad som fortfarande är osäkert. |
| Gränser | Följer teamets granskningsregler och ber om hjälp eller information när auktoritet eller sammanhang saknas. |
Ankare: 0 betyder frånvarande eller ounderbyggt, 1 betyder delvis med relevanta utelämnanden och 2 betyder fullständigt och motiverat mot överenskomna kriterier. Definiera kritiska fel separat, till exempel att godkänna en ändring med en risk för dataförlust, så att en bra totalpoäng inte kan dölja en sådan. Anpassa kriterierna med teknikchefen; denna bedömningsmatris är ett utgångsförslag, inte en validerad beredskapsstandard. För mer information om poängsättning, se vår guide till utforma interaktiv praktik med användbar feedback.
Planera för överföring. Efter övningen, kontrollera ett urval av granskarens verkliga recensioner några veckor senare, med samma kriterier. Jämför med en baslinje som tagits före utbildningen och definiera population och tidpunkt i förväg. Titta på andra förändringar som skett under samma period, såsom ett nytt granskningsverktyg eller en personalförändring, innan du tillgodoräknar övningarna.
6. Kör övningen live eller i ditt eget tempo med AhaSlides
Du kan genomföra övningen i en workshop eller låta granskare arbeta igenom den på egen hand. Visa den förberedda ändringen i en livesession och använd interaktiva bilder för diskussionen:
- Välj svar för "vilken fråga skulle du ta upp först?", med de utvalda frågorna som alternativ. Visa spridningen innan du avslöjar din egen ranking.
- Öppna Avslutat för "skriv den kommentar du skulle lämna". Recensenter kan jämföra sina formuleringar med andra, vilket är där förklarande förmåga visar sig.
- Bedömningsskala för "hur allvarligt är detta?", så att gruppen kan se var bedömningarna skiljer sig åt och diskutera varför.
För granskare som inte kan närvara kan samma sekvens användas i egen takt, med den kommenterade expertgranskningen som visas efter varje svar. Behandla alla påståenden om kodkörning, integrationer eller AI-funktioner som obekräftade tills du har provat det med ditt eget material.
Om du även utbildar granskare i AI-skriven kod, se vår kompletterande guide om AI-genererad kodgranskningsutbildningDet inlägget handlar om granskning av genererad output. Det här handlar om hur människor granskar varandras arbete och hur de förklarar vad de hittar.
Begränsningar som kan finnas kvar
- Granskningstid. En eftertänksam kommentar tar längre tid än "LGTM", och deadlines tränger sig mot den kortare versionen.
- Lagnormer. Om feedback tolkas som personlig kritik kommer granskarna att mildra eller överge sina resultat.
- Falltäckning. En övning visar några typer av oro. En poäng beskriver inte en granskares bedömning i allmänhet.
- Överföra. Att prestera i en verkstad är inte detsamma som att prestera i en fullsatt kö, så kolla även riktiga recensioner.
Nämn dessa för sponsorer tidigt och planera separata åtgärder. Övningar förbättrar vad en granskare kan se och förklara. De skapar inte tid eller normer.
Vanliga frågor och svar
Vad är kodgranskningsövningar?
Det är förberedda övningsuppgifter där en utvecklare granskar en ändring med kända problem, skriver de kommentarer de skulle lämna och får feedback på noggrannhet och användbarhet. Syftet är att bygga upp granskarens skicklighet, inte att leverera ändringen.
Hur bedömer du om en granskares omdöme har förbättrats?
Ge en ny ändring som de inte har sett och poängsätt resultaten och förklaringen mot överenskomna kriterier. Kontrollera sedan ett urval av riktiga recensioner några veckor senare. Ett quiz om recensionsregler bekräftar endast förkunskapskraven.
Handlar peer code review främst om att hitta buggar?
Att hitta defekter är fortfarande en viktig motivation, men en studie på Microsoft fann att granskningar handlade mindre om defekter än förväntat och även ledde till kunskapsdelning och teammedvetenhet. Utforma övningar som belönar förklaring och förståelse samt antalet defekter.
Var ska man börja
Välj en typ av förändring som ditt team ofta granskar. Skriv prestationsutlåtandet, be en senior ingenjör att förbereda en förändring med tre eller fyra fröade problem och utarbeta en matris med tre kriterier med en skala från 0 till 2 och en lista över kritiska fel. Testa det med en liten grupp och jämför sedan deras nästa riktiga granskningar med en baslinje.
För att se hur en repetitionsövning kan köras live med ditt eget team och återanvändas i egen takt efteråt, utforska AhaSlides.
