Granska — vad är det, hur fungerar code review och PR-granskning

Vad är code review

Code review — är systematisk granskning av kod av kollegor före integration. I Git-sammanhang innebär detta: utvecklaren skapar en pull request med ändringar, utser granskare, och de studerar diffen, lämnar kommentarer och avger en dom. Granskaren kan begära ändringar (Request Changes), godkänna PR (Approve) eller lämna en allmän kommentar.

Code review har fem mål: förbättra kodkvalitet (upptäcka defekter innan de når produktion), sprida kunskap (granskaren lär sig nya angreppssätt, författaren får feedback), följa standarder (kontrollera överensstämmelse med code style och arkitekturbeslut), minska bus factor (koden är inte känd av endast en utvecklare) och bygga en ansvarskultur (författaren skriver noggrannare, med vetskapen att koden kommer att granskas).

Motsatsen till code review är blind commit: utvecklaren skickar ändringar till den gemensamma grenen utan granskning. Detta tillvägagångssätt är endast tillåtet i enanvändarprojekt eller för brådskande hotfixar med efterföljande granskning. I professionell teamutveckling är code review ett obligatoriskt steg för varje ändring, inklusive dokumentations- och konfigurationskorrigeringar.

Vad kontrolleras i code review

Code review bör vara systematisk, inte kaotisk. Erfarna granskare kontrollerar kod i en viss ordning: först arkitektur och logik, sedan tester, därefter säkerhet och prestanda, och slutligen — stil och namngivning. Denna ordning garanterar att kritiska problem uppmärksammas innan granskaren blir trött.

Arkitektur och logik: löser koden uppgiften, finns det onödiga abstraktioner, följs principerna SOLID och DRY. Komplex kod som är svår att förstå vid första läsningen — en signal att omfaktorisering behövs. Granskaren måste försäkra sig om att koden gör exakt vad som anges i uppgiften och inte har några bieffekter utanför sitt ansvarsområde.

Tester: täcker de nya testerna alla scenarier — positiva, negativa, gränsfall. Går befintliga tester igenom efter ändringarna. Finns det flaky-tester som misslyckas instabilt. Säkerhet: frånvaro av SQL-injektioner, XSS, läckage av känslig data via loggar eller API-svar. Prestanda: effektivitet hos algoritmer, överflödiga databasfrågor, resursläckage.

• Arkitektur — korrekthet i lösningen, efterlevnad av SOLID, frånvaro av over-engineering.
• Logik — hantering av alla scenarier, inklusive fel och gränsfall.
• Tester — täckning av nya ändringar, frånvaro av trasiga gamla tester.
• Säkerhet — injektioner, XSS, CSRF, dataläckage via loggar.
• Prestanda — komplexitet hos algoritmer, N+1-frågor, minnesläckage.

Granskningsstorlek: varför 400 rader är max

Begränsning av PR-storlek — den viktigaste metriken för code reviews effektivitet. Forskning av Cisco (2015) och efterföljande experiment av SmartBear och Google visade: vid en granskningsvolym över 400 rader sjunker granskarens förmåga att upptäcka defekter dramatiskt. Om PR överstiger 400 rader upptäcks fel med sannolikhet inte högre än slumpmässig.

Optimal storlek: 200-400 rader för en PR. Denna volym kan granskas av granskaren på 30-60 minuter, med bibehållen koncentration. Google rekommenderar inte mer än 200 rader för en granskningsomgång med full koncentration. Om det finns fler ändringar — bör uppgiften delas upp i flera på varandra följande PR, som var och en introducerar en logiskt avslutad ändring.

Granskningstid: inom 24 timmar från det att PR skapas. Om granskningen drar ut på tiden i flera dagar går uppgiftens kontext förlorad, och författaren måste lägga tid på att återställa kontexten när hen svarar på kommentarer. Team med hög code review-kultur sätter SLA för granskning: till exempel 4 timmar för kritiska ändringar och 24 timmar för vanliga.

Hur man skriver korrekta granskningskommentarer

Kommentarens ton — är avgörande för code reviews effektivitet. Kommentaren "Detta är felaktigt" utlöser en defensiv reaktion och ger inte författaren användbar information. Den bästa formuleringen är fråga-förslag: "Vad tycker du om detta tillvägagångssätt?", "Här kan NPE uppstå om user == nil. Kanske lägga till en guard?". Frågor pressar mindre och stimulerar diskussion.

Strukturen för en bra kommentar innehåller tre delar: vad som är fel, varför det är ett problem och hur man åtgärdar det. Exempel: "I denna slinga används O(n²) på grund av nästlad contains, vilket kan sakta ner vid 10k+ poster. Prova att ersätta med Set för O(1)-sökning". En sådan formulering anger samtidigt problemet, förklarar dess betydelse och föreslår en lösning — författaren behöver inte gissa.

GitHub och GitLab stöder suggestions — inbyggda förslag på kodändringar. Granskaren kan skriva: "```suggestion Filtrera tomma rader före bearbetning```" — och författaren tillämpar ändringen med ett klick. Detta påskyndar små korrigeringar och minskar antalet granskningsomgångar. För stora korrigeringar är det bättre att skriva en allmän kommentar än att placera stora block i suggestion.

# Mall för bra code review-kommentar

# DÅLIGT: "Den här koden är felaktig"
# BRA: "Vi kan förlora data vid tomt svar.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# GitHub-förslag syntax:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Code review-arbetsflöde i teamet

Ett effektivt granskningsarbetsflöde bygger på fyra steg. Första — författaren förbereder PR: skriver ett begripligt namn (t.ex. "feat: add password reset screen"), lägger till beskrivning av ändringar, länkar till uppgiften i tracker och testinstruktioner. Andra — författaren utser granskare via auto-assign (baserat på CODEOWNERS) eller manuellt.

Tredje steget — granskaren kontrollerar koden och lämnar kommentarer. Fjärde — författaren gör korrigeringar, svarar på kommentarer och begär omgranskning. Cykeln upprepas tills godkännande erhålls. Efter godkännande utför författaren merge (eller boten utför merge). Automatisering via Mergify eller GitHub Auto-merge påskyndar slutsteget.

En viktig del av arbetsflödet — hantering av inaktuella PR. Om en PR ligger utan granskning i mer än 3 dagar blockeras processen. Lösningar: rotation av granskare (om den utsedda granskaren inte är tillgänglig), meddelanden via Slack/Teams, tidsgräns för granskning (SLA). I vissa team stängs en PR utan granskning i mer än 7 dagar automatiskt, och författaren skapar en ny efter synkronisering med main.

• Skapa PR — begripligt namn, beskrivning, länkar till uppgift, skärmbilder vid UI-ändringar.
• Utse — auto-assign via CODEOWNERS eller manuellt val av 1-2 granskare.
• Granskning — kontroll i ordning: arkitektur → logik → tester → säkerhet → stil.
• Korrigeringar — författaren svarar på alla kommentarer, åtgärdar blocking issues, begär omgranskning.
• Merge — efter godkännande och grön CI utför författaren eller boten sammanslagningen.

Typiska misstag i code review

Första misstaget — ytlig granskning. Granskaren tittar snabbt igenom diffen, utan att fördjupa sig i logiken, och trycker på Approve. Orsaker: stor PR, deadline, trötthet. Konsekvenser: buggar når produktion. Lösning: om du inte har tid för kvalitativ granskning — skriv ärligt "Jag kan inte kontrollera idag, skjut upp till imorgon" istället för formellt godkännande.

Andra misstaget — överdriven kritik (nitpicking). Granskaren lämnar dussintals kommentarer om formateringsstil, variabelnamn, triviala detaljer. Detta demotiverar författaren och förlänger granskningen. Lösning: StyleGuide och linters bör kontrollera stil automatiskt. Människan i granskningen kontrollerar logik, arkitektur och säkerhet.

Tredje misstaget — granskning utan frågor. Om granskaren bara sätter Request Changes och Approve, men inte ställer frågor, missar han möjligheten att lära sig något nytt. Den bästa indikatorn på en sund code review är förekomsten av diskussioner där båda parter lär sig något nytt. Om granskningen är en monolog av en av deltagarna — är processen trasig.

• Ytlig granskning — Approve utan fördjupning. Lösning: granska inte om du inte har tid.
• Nitpicking — kritik av stil som kontrolleras av linter. Lösning: automatisera style checks.
• Personlig uppfattning — "jag skulle ha skrivit annorlunda". Lösning: koden ska fungera, inte behaga granskaren.
• Förlängning — granskning längre än 24 timmar. Lösning: SLA för granskning, eskalering vid överträdelse.
• Ignorera kontext — kodgranskning utan att förstå uppgiften. Lösning: läs PR-beskrivningen före diffen.