Code review-kultur og bedste praksis for PR'er

Kodegennemgang handler ikke om gatekeeping — det er sådan, teams lærer sammen, overdrager ejerskab og holder kvaliteten høj. En god kultur for kodegennemgang løfter hele teamet; en dårlig kultur skaber flaskehalse og bitterhed.

1) Hold den lille (helst under 400 linjer). 2) Skriv en tydelig beskrivelse: hvorfor, hvad og hvordan den skal testes. 3) Link til opgaven. 4) Tilføj skærmbilleder eller videoer ved ændringer i brugergrænsefladen. 5) Gennemgå selv dine ændringer, før du beder andre om at gennemgå dem.

Brug de samme konventionelle præfikser som til commits: feat: add user profile page, fix: handle 404 in fetch wrapper, refactor: extract Avatar component. Mange teams genererer ændringslogge ud fra dem.

De fleste teams bruger en PR-skabelon — installér den i .github/pull_request_template.md.

Før du beder andre om at gennemgå dine ændringer, skal du gå din egen ændringsforskel igennem linje for linje. Tilføj kommentarer, der forklarer valg, som ikke er indlysende. Ofte opdager du dine egne fejl, før en anden behøver at gøre det.

En PR på 2000 linjer bliver sjældent gennemgået grundigt. Opdel den i: 1) refaktorering (ingen ændring af adfærd), 2) ny adfærd, 3) finpudsning af brugergrænsefladen. Så er hver del nemmere at gennemgå og rulle tilbage.

Formulér feedback som spørgsmål, ikke ordrer: „Hvad synes du om at udtrække dette til en hook?“ er bedre end „udtræk dette“. Skeln mellem det, der absolut skal rettes, og det, der blot ville være rart at få med. Brug præfikser: nit:, question:, blocker:.

„Det her er forvirrende“ fortæller ikke forfatteren noget. „Jeg måtte læse det tre gange for at forstå den tidlige returnering — kan vi udtrække en guard-betingelse?“ giver forfatteren noget konkret at handle på.

Kommentér positivt på elegante løsninger, gode navne og nyttige tests. Det opmuntrer til at bruge de samme mønstre og gør resten af feedbacken lettere at tage imod. PR'er, der kun får kritik, føles konfronterende.

Prettier håndterer formatering. ESLint håndterer stil. Spild ikke gennemgangstid på tabulatorer kontra mellemrum. Hvis en stilregel bliver ved med at dukke op, så kod den ind i linteren.

Tests er også kode. Sørg for, at ny kode har tests. Kontrollér, at testene faktisk afprøver det rigtige — mange tests består, selv når koden er i stykker, fordi de kontrollerer det forkerte.

Svar på enhver kommentar — også selvom det kun er med en tommel-op-emoji. Gør indsigelse mod forslag, du er uenig i (du skrev koden og kan have en vigtig kontekst). Markér afsluttede tråde som afsluttede. Opdatér PR-beskrivelsen, hvis omfanget ændrer sig.

Gennemgå inden for én arbejdsdag. Forældede PR'er mister kontekst — forfatteren er kommet videre, og grenen skal måske rebase'es. Store PR'er, der ligger en uge, ender altid som frygtelige sammenfletninger.

GitHubs forslagsfunktion lader forfatteren acceptere en rettelse med ét klik. Det er meget hurtigere end at skrive „ændr denne linje til X“ som brødtekst.

Godkend, når: koden er korrekt, testene består, du forstår ændringen, og det er sikkert at flette den ind. Når du godkender, tager du medejerskab for resultatet. Godkend ikke ukritisk — hvis du ikke har læst koden, så sig det.

Forfatter: små, velforklarede PR'er med skærmbilleder og tests. Gennemgå selv først. Gennemgår: konstruktiv, spørgsmålsbaseret feedback. Skeln mellem en blokering og en bagatel. Ros det gode. Spring stil over — lad værktøjerne håndtere den. Gennemgå inden for en dag. Godkend kun, når du forstår ændringen. PR-skabeloner standardiserer processen. Gennemgange er samarbejde, ikke gatekeeping.