Kodegjennomgangskultur og beste praksis for PR-er

Kodegjennomgang handler ikke om portvokting – det er slik team lærer sammen, overfører eierskap og holder kvaliteten høy. En god kultur for kodegjennomgang løfter hele teamet; en dårlig kultur skaper flaskehalser og bitterhet.

1) Hold den liten (under 400 linjer hvis mulig). 2) Skriv en tydelig beskrivelse: hvorfor, hva og hvordan den testes. 3) Koble den til saken. 4) Legg til skjermbilder eller videoer ved endringer i brukergrensesnittet. 5) Gå gjennom diffen Deres selv før De ber om gjennomgang.

Bruk de samme konvensjonelle prefiksene som for commits: feat: add user profile page, fix: handle 404 in fetch wrapper, refactor: extract Avatar component. Mange team genererer endringslogger fra disse.

De fleste team bruker en PR-mal – installer den i .github/pull_request_template.md.

Før De ber om gjennomgang, gå gjennom Deres egen diff linje for linje. Legg til kommentarer som forklarer valg som ikke er åpenbare. Ofte oppdager De egne feil før noen andre må gjøre det.

En PR på 2000 linjer blir sjelden grundig gjennomgått. Del den opp i: 1) refaktorering (ingen endring i oppførsel), 2) ny funksjonalitet, 3) finpussing av brukergrensesnittet. Hver del er enklere å gjennomgå og tilbakestille.

Formuler det som spørsmål, ikke ordrer: «Hva synes De om å trekke dette ut i en hook?» er bedre enn «trekk dette ut». Skill mellom det som må fikses og det som bare er kjekt å ha. Bruk prefikser: nit:, question:, blocker:.

«Dette er forvirrende» forteller ikke forfatteren noe. «Jeg måtte lese dette tre ganger for å forstå den tidlige returen – kan vi trekke ut en guard clause?» gir forfatteren noe konkret å handle på.

Kommenter positivt på smarte løsninger, gode navn og nyttige tester. Det oppmuntrer til slike mønstre og gjør resten av tilbakemeldingen lettere å ta imot. PR-er som bare får kritikk, oppleves som konfronterende.

Prettier håndterer formatering. ESLint håndterer stil. Ikke kast bort gjennomgangsrunder på tabulatorer kontra mellomrom. Hvis en stilregel stadig dukker opp, bør den bygges inn i linteren.

Tester er også kode. Sørg for at ny kode har tester. Kontroller at testene faktisk tester det riktige — mange tester består selv når koden er ødelagt, fordi de sjekker feil ting.

Svar på alle kommentarer – selv om det bare er med en tommel opp-emoji. Si imot forslag De er uenig i (De skrev koden og kan ha kontekst de andre mangler). Marker løste tråder som løst. Oppdater PR-beskrivelsen hvis omfanget endres.

Gjennomfør gjennomgangen innen én arbeidsdag. Foreldede PR-er mister kontekst – forfatteren har gått videre, og grenen trenger rebase. Store PR-er som blir liggende en uke, ender alltid i marerittaktige sammenslåinger.

Forslagsfunksjonen i GitHub lar forfatteren godta en rettelse med ett klikk. Det går mye raskere enn å skrive «endre denne linjen til X» i løpende tekst.

Godkjenn når: koden er korrekt, testene består, De forstår endringen, og den er trygg å slå sammen. En godkjenning betyr at De tar medansvar for resultatet. Ikke godkjenn på autopilot – hvis De ikke har lest den, si fra.

Forfatter: små, godt beskrevne PR-er med skjermbilder og tester. Gjennomfør en egen gjennomgang først. Gjennomgår: konstruktive, spørsmålsbaserte tilbakemeldinger. Skill mellom blokkere og småting. Gi ros for det som er bra. Hopp over stil – la verktøyene håndtere det. Gjennomfør gjennomgangen innen én dag. Godkjenn bare når De forstår endringen. PR-maler standardiserer prosessen. Gjennomganger er samarbeid, ikke portvokting.