Code Review — essens, regler och hur man genomför granskning i teamet

Vad är Code Review?

Code Review — processen att granska källkod av en eller flera utvecklare innan den integreras i projektets huvudgren. Syftet med granskningen är inte bara att hitta fel, utan också att förbättra arkitekturen, följa teamstandarder och sprida kunskap. Till skillnad från automatisk analys (linters) utförs code review av en människa och utvärderar läsbarhet, logik och arkitektoniska beslut.

Enligt Google Engineering Practices, 2024 delas Code Review in i två likvärdiga mål: skydda kodbasen från defekter och utbilda utvecklare genom feedback. I mobila projekt omfattar granskningen obligatoriskt kontroll av ramverk (UIKit, SwiftUI, Jetpack Compose), minneshantering och arbete med nätverksförfrågningar.

Code Review i GitLab och GitHub organiseras via Merge Request och Pull Request. Varje MR/PR innehåller diff, kommentarer på rader, diskussioner och granskningsstatus. Enligt forskning från Microsoft Research (2023) släpper team som praktiserar regelbunden granskning 40% färre kritiska buggar till produktion.

Code Reviews historia: från formella inspektioner till asynkrona PR

Den första formella Code Review uppstod på IBM på 1970-talet som „strukturerade inspektioner" med steg-för-steg-checklistor och protokoll. På 2000-talet med spridningen av Git och distribuerade team utvecklades granskningen till ett asynkront format via Pull Request. GitHub (2008) gjorde PR till ett massfenomen. Modern Code Review är en informell, asynkron process med fokus på hastighet och lärande, inte byråkrati.

Typer av Code Review: formella och informella angreppssätt

Code Review klassificeras i fyra huvudtyper beroende på process och deltagarnas engagemang. Formell (Asynchronous Review) — granskning via MR/PR utan synkron kommunikation, vanligast i distribuerade team. Informell — quick CR, när en utvecklare går fram till en annan och ber om att få titta på koden inom 5 minuter.

Enligt Microsoft Research, 2023 är parprogrammering (Pair Programming) — två utvecklare arbetar vid en skärm, varje kod skrivs i realtid med granskning „i farten". Over-the-shoulder — en utvecklare tittar på en annans skärm och kommenterar koden utan formell process. Walkthrough — kodens författare leder en grupp utvecklare genom ändringarna och förklarar varje beslut.

Code Review-checklista: vad man ska kontrollera i koden

Code Review-checklistan hjälper granskaren att inte missa kritiskt viktiga aspekter. Första kategorin — korrekthet och arkitektur: motsvarar lösningen den givna uppgiften, finns det överdriven komplexitet, är mönstren (MVP, MVVM, Clean Architecture) korrekt valda. Andra kategorin — stil och formatering: följs teamets kodstil (Kotlin Code Style, Swift Style Guide).

Enligt Thoughtbot Code Review Guide, 2024 är tredje blocket — testning: är enhetstester skrivna, täcker de gränsfall, har de inte brutit befintliga tester. Fjärde — säkerhet: finns det hårdkodade token, API-nycklar, SQL-injektioner, minnesläckor. Femte — prestanda: används korutiner/RxJava korrekt, finns det blockering av UI-tråden, överdrivna allokeringar.

• Logik — algoritmens korrekthet, hantering av gränsfall och fel
• Arkitektur — efterlevnad av Clean Architecture, MVVM, separation av ansvar
• Kodstil — namngivning, formatering, konsistens med projektet
• Tester — förekomst av enhetstester, deras fullständighet och grön status

Hur man genomför Code Review: regler för granskaren

Code Review kräver av granskaren en balans mellan noggrannhet och hastighet. Huvudregel — granska koden i små portioner. Optimal volym — 200–400 rader ändringar per session. Enligt Google Research (2022) förlorar granskning över 500 rader effektivitet: antalet missade defekter ökar linjärt med ändringarnas volym. Andra regeln — börja med arkitektur, sedan logik, sedan detaljer.

Enligt SmartBear, 2025 ska kommentarer vara specifika: inte „det här är dåligt", utan „den här metoden bryter mot SRP — flytta valideringslogiken till en separat klass". Varje kommentar är ett förslag till förbättring, inte kritik. Om koden är korrekt men stilen inte matchar granskarens preferenser — lämna utan kommentar. Granskaren ska godkänna den korrekta lösningen, även om han själv skulle ha skrivit annorlunda.

Hur man tar emot Code Review: tips för författaren

Att ta emot Code Review — en färdighet inte mindre viktig än förmågan att granska kod. Författaren bör vara öppen för kommentarer och se dem som en möjlighet att förbättra lösningen. Första regeln — uppfatta inte kommentarer som personlig kritik. Code Review granskar koden, inte utvecklaren. Andra — om en kommentar är oklar, be om förtydligande, korrigera inte omedelbart.

Enligt LeadDev, 2024 måste författaren före sändning till granskning själv kontrollera sin kod: köra tester, gå igenom checklistan, försäkra sig om att det inte finns debug-logg och utkommenterad kod. MR/PR ska innehålla en begriplig beskrivning med sammanhang för ändringarna. Ju bättre beskrivning, desto snabbare och mer produktiv blir granskningen.

Psykologisk trygghet i Code Review

En central aspekt av Code Review — psykologisk trygghet i teamet. Om en utvecklare är rädd för att få hård kritik eller förlöjligande kommer han att dölja problem istället för att diskutera dem. Google Project Aristotle (2017) visade: team med hög psykologisk trygghet är 25% mer produktiva. Regler: kritisera koden, inte författaren; ställ frågor istället för anklagelser; tacka för bra lösningar.

Nyckelregel för författaren — skynda inte att stänga kommentarer. Om granskaren har begärt ändringar måste de utföras, inte svara „ok" och lämna utan korrigering. Efter utförda korrigeringar — begär granskning igen. GitLab och GitHub stödjer Re-request Review för att meddela granskaren.

Automatisering av Code Review: linters och statisk analys

Automatisering av Code Review minskar bördan för utvecklare genom att eliminera kontroll av formella regler. Linters (ktlint, SwiftLint, ESLint) kontrollerar kodstil, formatering och grundläggande fel. Statiska analysatorer (Detekt, SonarQube, Infer) hittar potentiella buggar, minnesläckor och säkerhetsproblem innan koden når mänsklig granskning.

Enligt dokumentation för detekt, 2024 startas linters och analysatorer automatiskt i CI/CD-pipelinen när MR/PR skapas. Om kontrollen misslyckas blockeras MR med Merge-knappen. Detta garanterar att kod som når mänsklig granskning redan har passerat grundläggande kontroll. Granskaren fokuserar på arkitektur, logik och läsbarhet, inte på mellanrum och indrag.

// Exempel på detekt-konfiguration för Android-projekt
build.gradle.kts (app):

detekt {
    config = files("detekt-config.yml")
    buildUponDefaultConfig = true
    allRules = false
    autoCorrect = true
    debug = false
    parallel = true
}

tasks.named("preMerge") {
    dependsOn("detekt")
    dependsOn("ktlintCheck")
}

Verktyg för Code Review i mobila projekt

Code Review-verktyg inom mobilutveckling delas in i plattformsverktyg (GitLab, GitHub, Bitbucket) och specialiserade (Gerrit, Reviewable, Crucible). GitLab och GitHub tillhandahåller inbyggd funktionalitet: diff-jämförelse, kommentarer på rader, diskussionstrådar, statusar Approve/Changes Requested, integration med CI/CD. Valet av verktyg beror på teamets storlek och granskningspolicy.

Enligt GitLab Docs, 2025 ger Gerrit för stora team (50+ utvecklare) strängare kontroll: obligatorisk verifiering via CI före sammanslagning, viktade godkännanden (Verified + Code-Review) och detaljerade åtkomsträttigheter. För små och medelstora team är GitLab och GitHub det optimala valet: konfiguration av Required Approvals, Code Owners och Merge Checks tar minuter.

• GitLab — Approvals, Code Owners, Merge Checks, MR Templates, inbyggd CI/CD
• GitHub — Pull Requests, CODEOWNERS, Required Reviews, GitHub Actions
• Bitbucket — Pull Requests för Mercurial/Git, Approvals med Diff-kommentarer
• Gerrit — strikt verifieringsprocess, viktade bedömningar, Jenkins-integration

Vanliga misstag i Code Review

Misstag i Code Review minskar dess effektivitet och demotiverar teamet. Första — granskning av alltför stor volym ändringar på en gång. När MR innehåller 2000+ rader missar granskaren upp till 70% av defekterna. Andra — subjektiva kommentarer som inte baseras på kodstil eller arkitektur. Kommentarer som „jag skulle ha skrivit annorlunda" utan motivering ger ingen nytta.

Enligt Google Engineering Practices, 2024 är tredje misstaget — ignorering av tester. Om MR inte innehåller tester för ny funktionalitet bör granskaren kräva dem, inte godkänna „för senare". Fjärde — granskning i slutet av dagen eller sprinten när uppmärksamheten är spridd. Bästa tiden för granskning — första halvan av dagen, 30–60 minuter avsatta utan växling mellan uppgifter.

Säkerhet vid granskning — femte vanliga misstaget: granskare kontrollerar inte om det finns hårdkodade hemligheter, oskyddade WebView med JavaScript, sårbarheter i bibliotek. I mobila projekt är detta kritiskt: läckage av en API-nyckel kan leda till kompromettering av hela backend.

Code Review i distribuerade team

För distansteam är Code Review den huvudsakliga kanalen för kunskapsöverföring. Asynkront format via MR med tydliga deadlines rekommenderas: max 24 timmar för granskning. Använd skärminspelningar (Loom) för komplexa arkitekturdiskussioner. I distribuerade team är skriftlig dokumentation av beslut i MR-kommentarer särskilt viktig för att sammanhang inte ska gå förlorat vid byte av tidszoner.