Kodevurderingsøvelser: hvordan bruke fagfellevurdering til å utvikle analyse og teknisk vurdering

En utvikler åpner en pull-forespørsel som legger til en rabattberegning i en betalingstjeneste. Testene består, og differansen er kort. En anmelder godkjenner den på to minutter med "LGTM". Tre måneder senere må en lagkamerat endre den samme funksjonen og oppdager at den blander prisregler, avrunding og databasetilgang på ett sted. Ingen kan si med sikkerhet hva den har lov til å gjøre.

Dette er et illustrerende scenario, ikke en dokumentert hendelse. Det viser hva fagfellekodegjennomgang kan produsere når den fungerer som en læringsaktivitet: en anmelder som kan se en plausibel endring, oppdage problemet som ikke er en feil ennå, og forklare det på en måte forfatteren kan handle ut fra.

Denne veiledningen er for ledere innen ingeniørstøtte og ingeniørsjefer. Den viser hvordan man designer øvelser i kodegjennomgang som bygger den ferdigheten med vilje, i stedet for å håpe at anmeldere plukker den opp fra køen. Den dekker ytelsesproblemet, hullene som må diagnostiseres, hvordan man strukturerer forberedelser og øvelser, ett praktisert eksempel, og hvordan man sjekker at ferdigheten overføres til virkelige evalueringer. Få senioringeniører til å validere alle tilfeller, feil og kriterier før du bruker dem.

Hva er kodegjennomgangsøvelser?

Kodegjennomgangsøvelser er strukturerte øvingsoppgaver der en utvikler gjennomgår en forberedt endring, forklarer hva de fant og hvorfor det er viktig, og får tilbakemelding på kvaliteten på forklaringen. De er forskjellige fra gjennomgangene teamet ditt gjør hver dag. Endringen er valgt på forhånd, bekymringene i den er kjente, og målet er å forbedre den som anmelder snarere enn å levere endringen.

Kjappe fakta

1. Beskriv ytelsesproblemet

Start med oppgaven, i én setning: gitt en endring, forklarer anmelderen hva de fant, hvorfor det er viktig og hva forfatteren kan gjøre med det. «Forklarer» er det viktige ordet. Å oppdage et problem er halve ferdigheten. Å si det slik at en kollega med et annet syn kan forstå det, vurdere det og handle er den andre halvdelen.

Forskning på moderne kodegjennomgang støtter å se utover feilsøking. I en studie hos Microsoft observerte, intervjuet og spurte Bacchelli og Bird utviklere og ledere. De fant ut at det å finne feil fortsatt var hovedmotivasjonen for gjennomgang, men at gjennomganger handlet mindre om feil enn folk forventet. De ga også andre fordeler, som kunnskapsdeling, teambevissthet og alternative løsninger, og forskerne beskrev kode- og endringsforståelse som det viktigste aspektet ved gjennomgang (Bacchelli og Bird, ICSE 2013). Det er en studie av ett selskaps team, så bruk det som en grunn til å designe for forståelse, ikke som en sats for dine egne.

Googles publiserte gjennomgangsstandard peker i samme retning. Den forteller anmeldere at de bør favorisere godkjenning av en endring når den definitivt forbedrer kodens generelle tilstand, selv om den ikke er perfekt, og den sier at gjennomgang kan lære utviklere noe nytt, så kommentarer som hjelper noen å lære er velkomne (Googles tekniske praksisBegge kildene beskriver gjennomgang som et sted hvor vurdering utøves og felles. Det er det øvelsene dine bør øve på.

2. Diagnostiser lærings- og konteksthullene

Sammenlign oppgaven med det ditt nåværende program praktiserer og vurderer.

1. Bruker dagens praksis den virkelige oppgaven? Hvis nye anmeldere lærer ved å lese en stilguide og deretter gjennomgå live pull requests, øver de på ekte arbeid uten noe trygt sted å ta feil. Hvis vurdering er en quiz i anmeldelsesetikette, måler den hukommelse av reglene, ikke evnen til å anvende dem på en endring.
2. Hva er den kognitive etterspørselen? I den reviderte Blooms taksonomi ligger vurderingen av om et design er forsvarlig og avveiningen av avveiningene på analyse- og evalueringsnivåene, og forslag til en bedre struktur når skapernivået. Hvis øvelsene dine bare spør «hva gjør denne koden?», stopper de ved forståelse. Vår guide til matche læringsaktiviteter med Blooms taksonomi viser hvordan man kan tilpasse aktiviteten til nivået.
3. Er det noe annet enn ferdigheter som kommer i veien? Sjekk gjennomgangstid, verktøy, eierskap og teamnormer. Hvis anmelderne har fem minutter per pull-forespørsel, vil ingen øvelse gi en gjennomtenkt forklaring. Hvis forfatterne tar alle kommentarer som kritikk, vil anmelderne myke opp funnene sine til de ikke sier noe. Rapporter disse årsakene til de som kan fikse dem.

3. Designforberedelse, øving og tilbakemelding

Gi hvert trinn en egen jobb.

Forberedelse. Sjekk hva anmelderne trenger før de starter: teamets sjekkliste for gjennomgang, designprinsippene den er basert på, og hvordan man leser en differanse i verktøyet ditt. Hold dette i eget tempo og kort. En tilbakekallingssjekk bekrefter kun forkunnskaper, og det er ikke bevis på at noen kan gjennomgå.

Øve på. Bruk forberedte endringer med et lite antall innledede bekymringer av ulik art: en korrekthetsfeil, et vedlikeholdsproblem som de blandede ansvarsområdene i åpningseksemplet, et uklart navn eller manglende test, og noe kode som er grei. Be anmelderen om å skrive kommentaren de vil legge igjen, rangere bekymringene og si hvilken ytterligere informasjon de ønsker. CodeRefinerys praktiske leksjon viser formen: folk åpner en pull-forespørsel som inneholder en liten skrivefeil og en større feil, og deretter gjennomgår den som en fagfelle (CodeRefinery, Øving på kodegjennomgang). Bygg din egen kodebase, slik at konvensjonene og avveiningene er reelle.

Feedback. Koble det til avgjørelsene anmelderen tok. «Du la merke til avrundingsproblemet, men kommentaren din sa 'dette ser feil ut' uten å si hvilke input-elementer som feiler» er mer nyttig enn «funnet 2 av 4».

Live input eller asynkron gjennomgang? Live-innspill gir mest verdi når en bekymring er tvetydig, og anmeldere lærer av å høre en senioringeniør si hvorfor de ville ta den opp, eller la den ligge. Asynkron gjennomgang er nok for å sammenligne kommentarer med en kommentert ekspertgjennomgang.

4. Arbeid deg gjennom et realistisk eksempel

Illustrativt. En ingeniørsjef bør validere tilfellet og svarkriteriene før bruk.

Saken. En endring legger til en rabattberegning i en kassetjeneste. Den består testene. I én funksjon bruker den prosentvise og faste rabatter, avrunder resultatet, skriver til databasen og sender en hendelse. Den har én test, for en enkelt prosentvis rabatt.

Oppgaven. Anmelderen skriver kommentarene de ville lagt igjen, rangerer bekymringene sine og sier hva de trenger å vite før de godkjenner.

Et første forsøk. «Ser greit ut, testen består. Kanskje dele den opp?» Anmelderen har lagt merke til noe, men har ikke sagt hva, hvorfor det er viktig eller hva man skal gjøre. Forfatteren kan ikke gjøre noe ut fra dette.

Tilbakemelding og prøv på nytt. Tilretteleggeren spør: hva ville en fremtidig endring i denne funksjonen risikere å bryte? Hva ville du bedt forfatteren om å legge til før du godkjenner? Det nye forsøket ber om en spesifikk kommentar til hvert problem, med begrunnelse og et forslag.

Et sterkere forsøk. «Funksjonen bruker to typer rabatter: runder, lagrer og publiserer en hendelse, så en endring i avrunding kan endre hva vi lagrer og hva vi publiserer samtidig. Jeg ville bedt om at prisreglene flyttes til en ren funksjon vi kan teste på egenhånd. Enkelttesten dekker bare en prosentvis rabatt. Jeg ville bedt om en fast rabatt og en ordre som bringer totalen til null. Jeg er ikke sikker på om hendelsen er ment å utløses når totalen er null, så jeg ville spurt forfatteren.» Legg merke til at denne kommentaren navngir bekymringen, gir årsaken, kommer med et konkret forslag og angir hva anmelderen ikke vet.

5. Vurder kapasitet og planoverføring

Bevis på evne er ytelse på en ny endring som anmelderen ikke har sett. Gi poeng for nøyaktigheten av funnene og nytten av forklaringen. En enkel rubrikk bruker en skala fra 0 til 2 per kriterium:

Ankere: 0 betyr fraværende eller ikke støttet, 1 betyr delvis med relevante utelatelser, og 2 betyr fullstendig og begrunnet mot avtalte kriterier. Definer kritiske feil separat, for eksempel godkjenning av en endring med risiko for datatap, slik at en god samlet poengsum ikke kan skjule en. Tilpass kriteriene med ingeniørsjefen; denne rubrikken er et startforslag, ikke en validert beredskapsstandard. For mer om poengbegrunnelse, se vår veiledning til utforme interaktiv praksis med nyttig tilbakemelding.

Planlegg overføring. Etter øvelsen, sjekk et utvalg av evaluatorens faktiske evalueringer noen uker senere, med de samme kriteriene. Sammenlign med en baseline tatt før opplæringen og definer populasjonen og tidspunktet på forhånd. Se på andre endringer som skjedde i samme periode, for eksempel et nytt evalueringsverktøy eller en endring i bemanning, før du gir godskriving til øvelsene.

6. Kjør øvelsen live eller i ditt eget tempo med AhaSlides

Du kan kjøre øvelsen i et verksted eller la evaluatorene jobbe seg gjennom den på egenhånd. I en live-sesjon kan du vise den forberedte endringen og bruke interaktive lysbilder til diskusjonen:

1. Velg svar for «hvilken bekymring ville du tatt opp først?», med de oppgitte bekymringene som alternativer. Vis spredningen før du avslører din egen rangering.
2. Åpen slutt for «skriv kommentaren du ville lagt igjen». Anmeldere kan sammenligne formuleringen sin med andres, og det er her forklaringsevnen viser seg.
3. Karakterskala for «hvor alvorlig er dette?», slik at gruppen kan se hvor vurderingene er forskjellige og snakke om hvorfor.

For anmeldere som ikke kan delta, kan samme sekvens brukes i eget tempo, med den kommenterte ekspertanmeldelsen vist etter hvert svar. Behandle enhver påstand om kodeutførelse, integrasjoner eller AI-funksjoner som ubekreftet inntil du har prøvd det med ditt eget materiale.

Hvis du også lærer opp anmeldere i AI-skrevet kode, se vår tilhørende veiledning om Opplæring i AI-generert kodegjennomgangDet innlegget handler om å revidere generert output. Dette handler om hvordan folk vurderer hverandres arbeid, og hvordan de forklarer hva de finner.

Begrensninger som kan gjenstå

• Gjennomgangstid. En gjennomtenkt kommentar tar lengre tid enn «LGTM», og tidsfrister presser seg mot den korte versjonen.
• Lagnormer. Hvis tilbakemeldinger leses som personlig kritikk, vil anmelderne myke opp eller droppe funnene sine.
• Saksdekning. Én øvelse viser noen typer bekymringer. En poengsum beskriver ikke en anmelders vurdering generelt.
• Overføre. Å yte på et verksted er ikke det samme som å yte i en travel kø, så sjekk også ekte anmeldelser.

Navngi disse til sponsorene tidlig og planlegg separate løsninger. Øvelser forbedrer hva en anmelder kan se og forklare. De skaper ikke tiden eller normene.

Ofte stilte spørsmål

Hva er kodegjennomgangsøvelser?

De er forberedte øvingsoppgaver der en utvikler gjennomgår en endring med kjente bekymringer, skriver kommentarene de ville lagt igjen og får tilbakemelding på nøyaktighet og nytteverdi. Målet er å bygge opp anmelderens ferdigheter, ikke å levere endringen.

Hvordan vurderer du om en anmelders dømmekraft har blitt bedre?

Gi en ny endring de ikke har sett, og score funnene og forklaringen mot avtalte kriterier. Sjekk deretter et utvalg av reelle anmeldelser noen uker senere. En quiz om vurderingsregler bekrefter kun forkunnskapene.

Handler fagfellekodevurdering hovedsakelig om å finne feil?

Å finne feil er fortsatt en hovedmotivasjon, men en studie hos Microsoft fant at evalueringer handlet mindre om feil enn forventet, og at de også leverte kunnskapsdeling og teambevissthet. Designøvelser som belønner forklaring og forståelse, samt antall feil.

Hvor skal jeg starte

Velg én type endring som teamet ditt ofte gjennomgår. Skriv en resultatrapport, be en senioringeniør om å forberede én endring med tre eller fire problemstillinger, og utarbeid en rubrikk med tre kriterier, en skala fra 0 til 2 og en liste over kritiske feil. Test det med en liten gruppe, og sammenlign deretter deres neste virkelige gjennomganger med et referansepunkt.

For å se hvordan en repetisjonsøvelse kan kjøres live med ditt eget team, og brukes om igjen i ditt eget tempo etterpå, kan du utforske AhaSlides.