Code Review — lényege, szabályai és hogyan végezz ellenőrzést a csapatban

Mi az a Code Review?

Code Review — a forráskód ellenőrzésének folyamata egy vagy több fejlesztő által, mielőtt az beintegrálásra kerül a projekt fő ágába. Az ellenőrzés célja nem csak a hibák megtalálása, hanem az architektúra javítása, a csapat szabványainak való megfelelés és a tudás terjesztése. Az automatikus elemzéssel (linterekkel) ellentétben a kódellenőrzést ember végzi, és értékeli az olvashatóságot, a logikát és az architekturális döntéseket.

A Google Engineering Practices, 2024 szerint a Code Review két egyenrangú célra oszlik: a kódbázis védelme a hibáktól és a fejlesztők képzése visszajelzésen keresztül. Mobil projektekben az ellenőrzés kötelezően magában foglalja a keretrendszerek (UIKit, SwiftUI, Jetpack Compose), a memóriakezelés és a hálózati kérésekkel való munka ellenőrzését.

A Code Review a GitLab-ban és a GitHub-ban Merge Request és Pull Request útján szerveződik. Minden MR/PR tartalmaz diff-et, soregységenkénti megjegyzéseket, megbeszéléseket és ellenőrzési státuszokat. A Microsoft Research (2023) kutatása szerint a rendszeres ellenőrzést végző csapatok 40%-kal kevesebb kritikus hibát szállítanak éles környezetbe.

A Code Review története: a formális inspekcióktól az aszinkron PR-ekig

Az első formális Code Review az IBM-nél jelent meg az 1970-es években mint „strukturált inspekció" lépésről lépésre ellenőrző listákkal és protokollal. A 2000-es években a Git és az elosztott csapatok elterjedésével az ellenőrzés aszinkron formátummá fejlődött a Pull Requesten keresztül. A GitHub (2008) tömegjelenséggé tette a PR-t. A modern Code Review informális, aszinkron folyamat, amely a gyorsaságra és a tanulásra helyezi a hangsúlyt, nem a bürokráciára.

A Code Review típusai: formális és informális megközelítések

Code Review négy fő típusba sorolható a folyamattól és a résztvevők bevonásától függően. Formális (Asynchronous Review) — ellenőrzés MR/PR útján szinkron kommunikáció nélkül, legelterjedtebb az elosztott csapatokban. Informális — quick CR, amikor egy fejlesztő odamegy egy másikhoz, és megkéri, hogy 5 percen belül nézze meg a kódot.

A Microsoft Research, 2023 szerint a páros programozás (Pair Programming) — két fejlesztő dolgozik egy képernyő előtt, minden kód valós időben íródik „menet közbeni" ellenőrzéssel. Over-the-shoulder — egy fejlesztő a másik képernyőjére néz, és formális folyamat nélkül kommentálja a kódot. Walkthrough — a kód szerzője egy csoport fejlesztőt vezet végig a változtatásokon, elmagyarázva minden döntést.

Code Review ellenőrzési lista: mit ellenőrizzünk a kódban

A Code Review ellenőrzési lista segít a bírálónak, hogy ne hagyjon ki kritikusan fontos szempontokat. Első kategória — helyesség és architektúra: a megoldás megfelel-e a kitűzött feladatnak, van-e túlzott komplexitás, a minták (MVP, MVVM, Clean Architecture) helyesen lettek-e kiválasztva. Második kategória — stílus és formázás: betartják-e a csapat kódstílusát (Kotlin Code Style, Swift Style Guide).

A Thoughtbot Code Review Guide, 2024 szerint a harmadik blokk — tesztelés: írtak-e egységteszteket, lefedik-e a határesetecket, nem törtek-e el meglévő teszteket. Negyedik — biztonság: vannak-e keményre kódolt tokenek, API-kulcsok, SQL-injekciók, memóriaszivárgások. Ötödik — teljesítmény: helyesen használják-e a korutinokat/RxJava-t, van-e UI-szál blokkolás, túlzott foglalások.

• Logika — az algoritmus helyessége, határesetek és hibák kezelése
• Architektúra — a Clean Architecture, MVVM betartása, felelősségek szétválasztása
• Kódstílus — elnevezés, formázás, konzisztencia a projekttel
• Tesztek — egységtesztek megléte, teljességük és zöld státuszuk

Hogyan végezzük a Code Review-t: szabályok a bírálónak

Code Review egyensúlyt követel a bírálótól az alaposság és a gyorsaság között. Fő szabály — a kódot kis adagokban ellenőrizze. Optimális terjedelem — 200–400 sor változtatás egy ülésben. A Google Research (2022) szerint az 500 sor feletti ellenőrzés veszít a hatékonyságából: a kihagyott hibák száma lineárisan nő a változtatások mennyiségével. Második szabály — kezdje az architektúrával, aztán a logikával, majd a részletekkel.

A SmartBear, 2025 szerint a megjegyzéseknek konkrétnak kell lenniük: nem „ez rossz", hanem „ez a metódus megsérti az SRP-t — helyezze át a validációs logikát egy külön osztályba". Minden megjegyzés egy javaslat a fejlesztésre, nem kritika. Ha a kód helyes, de a stílus nem egyezik a bíráló preferenciáival — hagyja megjegyzés nélkül. A bírálónak jóvá kell hagynia a helyes megoldást, még akkor is, ha ő maga másképp írta volna.

Hogyan fogadjuk a Code Review-t: tanácsok a szerzőnek

A Code Review fogadása — nem kevésbé fontos készség, mint a kódellenőrzés képessége. A szerzőnek nyitottan kell hozzáállnia az észrevételekhez, és lehetőségként kell tekintenie a megoldás javítására. Első szabály — ne tekintse a megjegyzéseket személyes kritikának. A Code Review a kódot ellenőrzi, nem a fejlesztőt. Második — ha egy megjegyzés nem egyértelmű, kérjen pontosítást, ne javítsa azonnal.

A LeadDev, 2024 szerint az ellenőrzésre küldés előtt a szerzőnek saját magának kell ellenőriznie a kódját: futtassa le a teszteket, menjen végig az ellenőrzési listán, győződjön meg arról, hogy nincsenek debug naplók és kommentált kód. Az MR/PR-nek világos leírást kell tartalmaznia a változtatások kontextusával. Minél jobb a leírás, annál gyorsabb és produktívabb lesz az ellenőrzés.

Pszichológiai biztonság a Code Review-ban

A Code Review kulcsfontosságú aspektusa — a pszichológiai biztonság a csapatban. Ha egy fejlesztő fél az éles kritikától vagy a gúnyolódástól, elrejti a problémákat ahelyett, hogy megbeszélné azokat. A Google Project Aristotle (2017) kimutatta: a magas pszichológiai biztonsággal rendelkező csapatok 25%-kal produktívabbak. Szabályok: kritizálja a kódot, ne a szerzőt; tegyen fel kérdéseket vádaskodás helyett; köszönje meg a jó megoldásokat.

Kulcsszabály a szerző számára — ne siessen a megjegyzések lezárásával. Ha a bíráló változtatásokat kért, azokat el kell végezni, nem „ok"-kal válaszolni és javítás nélkül hagyni. A javítások elvégzése után — kérjen ismételt ellenőrzést. A GitLab és a GitHub támogatja a Re-request Review-t a bíráló értesítésére.

A Code Review automatizálása: linterek és statikus elemzés

A Code Review automatizálása csökkenti a fejlesztők terhelését a formális szabályok ellenőrzésének megszüntetésével. A linterek (ktlint, SwiftLint, ESLint) a kódstílust, formázást és alapvető hibákat ellenőrzik. A statikus elemzők (Detekt, SonarQube, Infer) potenciális hibákat, memóriaszivárgásokat és biztonsági problémákat találnak, mielőtt a kód emberi ellenőrzésre kerülne.

A detekt Dokumentáció, 2024 szerint a CI/CD csővezetékben a linterek és elemzők automatikusan elindulnak az MR/PR létrehozásakor. Ha az ellenőrzés nem sikerül — az MR blokkolva lesz a Merge gombbal. Ez garantálja, hogy az emberi ellenőrzésre olyan kód kerül, amely már átesett az alapellenőrzésen. A bíráló az architektúrára, logikára és olvashatóságra összpontosít, nem a szóközökre és behúzásokra.

// Példa detekt konfigurációra Android projekthez
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")
}

Eszközök a Code Review-hoz mobil projektekben

A Code Review eszközei a mobilfejlesztésben platform (GitLab, GitHub, Bitbucket) és speciális (Gerrit, Reviewable, Crucible) kategóriákra oszlanak. A GitLab és a GitHub beépített funkcionalitást nyújt: diff-összehasonlítás, soregységenkénti megjegyzések, beszélgetésszálak, Approve/Changes Requested státuszok, CI/CD-integráció. Az eszköz kiválasztása a csapat méretétől és az ellenőrzési politikától függ.

A GitLab Docs, 2025 szerint nagy csapatok (50+ fejlesztő) számára a Gerrit szigorúbb ellenőrzést biztosít: kötelező CI-verifikáció az egyesítés előtt, súlyozott jóváhagyások (Verified + Code-Review) és részletes hozzáférési jogok. Kis és közepes csapatok számára a GitLab és a GitHub az optimális választás: a Required Approvals, Code Owners és Merge Checks konfigurációja perceket vesz igénybe.

• GitLab — Approvals, Code Owners, Merge Checks, MR Templates, beépített CI/CD
• GitHub — Pull Requests, CODEOWNERS, Required Reviews, GitHub Actions
• Bitbucket — Pull Requests Mercurial/Githez, Approvals Diff-megjegyzésekkel
• Gerrit — szigorú verifikációs folyamat, súlyozott értékelések, Jenkins-integráció

Gyakori hibák a Code Review-ban

A Code Review-ban előforduló hibák csökkentik annak hatékonyságát és demotiválják a csapatot. Első — túl nagy mennyiségű változtatás egyszerre történő ellenőrzése. Amikor az MR 2000+ sort tartalmaz, a bíráló a hibák akár 70%-át is kihagyja. Második — szubjektív észrevételek, amelyek nem kódstíluson vagy architektúrán alapulnak. Az olyan megjegyzések, mint „én másképp írtam volna" indoklás nélkül nem hoznak hasznot.

A Google Engineering Practices, 2024 szerint a harmadik hiba — a tesztek figyelmen kívül hagyása. Ha az MR nem tartalmaz teszteket az új funkcióhoz — a bírálónak kérnie kell azokat, nem jóváhagyni „későbbre". Negyedik — ellenőrzés a nap vagy sprint végén, amikor a figyelem szétszórt. A legjobb idő az ellenőrzésre — a nap első fele, 30–60 perc elkülönítve feladatok közötti váltogatás nélkül.

Az ellenőrzés biztonsága — ötödik gyakori hiba: a bírálók nem ellenőrzik, hogy vannak-e keményre kódolt titkok, nem lezárt WebView-ok JavaScripttel, sebezhetőségek könyvtárakban. Mobil projektekben ez kritikus: egy API-kulcs kiszivárgása a teljes backend kompromittálódásához vezethet.

Code Review elosztott csapatokban

Távoli csapatok számára a Code Review a tudásátadás fő csatornája. Aszinkron formátum javasolt MR-en keresztül egyértelmű határidőkkel: maximum 24 óra az ellenőrzésre. Használjon képernyőfelvételeket (Loom) összetett architekturális megbeszélésekhez. Elosztott csapatokban különösen fontos a döntések írásos rögzítése az MR megjegyzésekben, hogy a kontextus ne vesszen el az időzónák változásakor.