Felülvizsgálni — mi ez, hogyan működik a code review és a PR ellenőrzés

Mi az a code review

Code review — a kód szisztematikus ellenőrzése kollégák által az integráció előtt. A Git kontextusában ez azt jelenti: a fejlesztő létrehoz egy pull request-et változtatásokkal, kijelöli a reviewereket, és azok tanulmányozzák a diff-et, megjegyzéseket hagynak és ítéletet hoznak. A reviewer kérhet változtatásokat (Request Changes), jóváhagyhatja a PR-t (Approve) vagy általános megjegyzést hagyhat.

A code review-nak öt célja van: a kód minőségének javítása (hibák felismerése, mielőtt production-be kerülnek), a tudás terjesztése (a reviewer új megközelítéseket ismer meg, a szerző visszajelzést kap), a szabványok betartása (a code style-nak és az architekturális döntéseknek való megfelelés ellenőrzése), a bus factor csökkentése (a kódot nem csak egy fejlesztő ismeri) és a felelősség kultúrájának építése (a szerző gondosabban ír, tudva, hogy a kódot ellenőrizni fogják).

A code review ellentéte a blind commit: a fejlesztő változtatásokat tol a közös ágba review nélkül. Ez a megközelítés csak egyfelhasználós projektekben vagy sürgős hotfix-ek esetén megengedett utólagos review-val. A professzionális csapatfejlesztésben a code review kötelező szakasz minden változtatáshoz, beleértve a dokumentációs és konfigurációs javításokat is.

Mit kell ellenőrizni a code review-ban

A code review-nak szisztematikusnak kell lennie, nem kaotikusnak. A tapasztalt reviewerek meghatározott sorrendben ellenőrzik a kódot: először architektúra és logika, aztán tesztek, majd biztonság és teljesítmény, és végül — stílus és elnevezés. Ez a sorrend garantálja, hogy a kritikus problémák észrevehetők legyenek, mielőtt a reviewer elfárad.

Architektúra és logika: megoldja-e a kód a feladatot, vannak-e felesleges absztrakciók, betartják-e a SOLID és DRY elveket. Az összetett kód, amelyet nehéz első olvasásra megérteni — jelzés, hogy refaktorálásra van szükség. A reviewer-nek meg kell győződnie arról, hogy a kód pontosan azt csinálja, ami a feladatban szerepel, és nincs mellékhatása a felelősségi körén kívül.

Tesztek: lefedik-e az új tesztek az összes forgatókönyvet — pozitív, negatív, határesetek. Átmennek-e a meglévő tesztek a változtatások után. Vannak-e flaky tesztek, amelyek instabilan esnek. Biztonság: SQL-injektálás, XSS, érzékeny adatok szivárgása naplókon vagy API-válaszokon keresztül. Teljesítmény: algoritmusok hatékonysága, felesleges adatbázis-lekérdezések, erőforrás-szivárgás.

• Architektúra — a megoldás helyessége, SOLID betartása, over-engineering hiánya.
• Logika — az összes forgatókönyv kezelése, beleértve a hibákat és határeseteket.
• Tesztek — az új változtatások lefedettsége, régi tesztek megtörésének hiánya.
• Biztonság — injektálás, XSS, CSRF, adatszivárgás naplókon keresztül.
• Teljesítmény — algoritmusok komplexitása, N+1 lekérdezések, memóriaszivárgás.

Review mérete: miért 400 sor a maximum

PR méretének korlátozása — a code review hatékonyságának legfontosabb mutatója. A Cisco (2015) kutatása és a SmartBear és Google későbbi kísérletei megmutatták: 400 sornál nagyobb review esetén a reviewer képessége a hibák felismerésére drasztikusan csökken. Ha a PR meghaladja a 400 sort, a hibák felismerésének valószínűsége nem magasabb a véletlenszerűnél.

Optimális méret: 200-400 sor egy PR-hez. Ekkora mennyiséget a reviewer 30-60 perc alatt ellenőrizhet, megtartva a koncentrációt. A Google legfeljebb 200 sort ajánl egy review körre teljes koncentrációval. Ha több a változtatás — a feladatot több egymást követő PR-re kell bontani, amelyek mindegyike logikailag befejezett változtatást hoz.

Review ideje: a PR létrehozásától számított 24 órán belül. Ha a review több napig elhúzódik, a feladat kontextusa elveszik, és a szerzőnek időt kell töltenie a kontextus helyreállításával a megjegyzésekre való válaszadáskor. A magas code review kultúrával rendelkező csapatok SLA-t állítanak be a review-ra: például 4 órát a kritikus változtatásokhoz és 24 órát a szokásosakhoz.

Hogyan írj helyes megjegyzéseket a review-hoz

A megjegyzések hangvétele — kritikus a code review hatékonysága szempontjából. Az "Ez helytelen" megjegyzés védekező reakciót vált ki, és nem ad hasznos információt a szerzőnek. A legjobb megfogalmazás a kérdés-javaslat: "Mit gondolsz erről a megközelítésről?", "Itt NPE léphet fel, ha user == nil. Esetleg guard hozzáadása?". A kérdések kevésbé nyomást gyakorolnak és ösztönzik a vitát.

A jó megjegyzés szerkezete három részből áll: mi a hiba, miért probléma és hogyan javítható. Példa: "Ebben a ciklusban O(n²) van használva a beágyazott contains miatt, ami lelassíthat 10k+ rekordnál. Próbáld meg Set-re cserélni O(1) kereséshez". Egy ilyen megfogalmazás egyszerre jelzi a problémát, magyarázza annak fontosságát és kínál megoldást — a szerzőnek nem kell találgatnia.

A GitHub és GitLab támogatja a suggestions-t — beépített kódváltoztatási javaslatokat. A reviewer írhatja: "```suggestion Üres sorok szűrése feldolgozás előtt```" — és a szerző egy kattintással alkalmazza a változtatást. Ez felgyorsítja a kis javításokat és csökkenti a review körök számát. Nagy javításokhoz jobb általános megjegyzést írni, mint nagy blokkokat elhelyezni a suggestion-ben.

# Sablon a jó code review megjegyzéshez

# ROSSZ: „Ez a kód helytelen“
# JÓ: „Adatokat veszíthetünk üres válasz esetén.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# GitHub javaslat szintaxis:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Code review workflow a csapatban

A hatékony review workflow négy szakaszon alapul. Első — a szerző előkészíti a PR-t: érthető nevet ír (pl. "feat: add password reset screen"), hozzáadja a változtatások leírását, hivatkozásokat a trackerben lévő feladatra és tesztelési utasításokat. Második — a szerző kijelöli a reviewereket auto-assign-en (CODEOWNERS alapján) vagy manuálisan.

Harmadik szakasz — a reviewer ellenőrzi a kódot és megjegyzéseket hagy. Negyedik — a szerző elvégzi a javításokat, válaszol a megjegyzésekre és kéri az ismételt review-t. A ciklus addig ismétlődik, amíg meg nem történik a jóváhagyás. A jóváhagyás után a szerző elvégzi a merge-t (vagy a bot végzi a merge-t). Az automatizálás a Mergify-n vagy GitHub Auto-merge-en keresztül felgyorsítja a végső szakaszt.

A workflow fontos eleme — az elavult PR-ek kezelése. Ha egy PR több mint 3 napig review nélkül marad, a folyamat blokkolódik. Megoldások: reviewerek rotációja (ha a kijelölt reviewer nem elérhető), értesítések Slack/Teams-en keresztül, időkorlát a review-ra (SLA). Egyes csapatokban a 7 napnál tovább review nélküli PR automatikusan bezárul, és a szerző újat hoz létre a main-nel való szinkronizálás után.

• PR létrehozása — érthető név, leírás, hivatkozások a feladatra, képernyőképek UI-változtatásoknál.
• Kijelölés — auto-assign CODEOWNERS-en keresztül vagy 1-2 reviewer manuális kiválasztása.
• Review — ellenőrzés sorrendben: architektúra → logika → tesztek → biztonság → stílus.
• Javítások — a szerző válaszol az összes megjegyzésre, javítja a blocking issue-kat, kéri a re-review-t.
• Merge — jóváhagyás és zöld CI után a szerző vagy bot elvégzi az egyesítést.

A code review tipikus hibái

Első hiba — felszínes review. A reviewer futólag átnézi a diff-et, nem mélyed el a logikában, és megnyomja az Approve-t. Okok: nagy PR, deadline, fáradtság. Következmények: bugok kerülnek a production-be. Megoldás: ha nincs idő a minőségi review-ra — írd meg őszintén "Ma nem tudom ellenőrizni, halaszd holnapra" a formális jóváhagyás helyett.

Második hiba — túlzott kritika (nitpicking). A reviewer tucatnyi megjegyzést hagy a formázási stílusról, változónevekről, triviális részletekről. Ez demotiválja a szerzőt és elnyújtja a review-t. Megoldás: a StyleGuide-nak és a lintereknek automatikusan kell ellenőrizniük a stílust. Az ember a review-ban a logikát, architektúrát és biztonságot ellenőrzi.

Harmadik hiba — review kérdések nélkül. Ha a reviewer csak Request Changes-t és Approve-t tesz, de nem tesz fel kérdéseket, elveszíti az esélyt, hogy újat tanuljon. A code review egészségének legjobb mutatója a viták jelenléte, amelyekben mindkét fél tanul valami újat. Ha a review az egyik résztvevő monológa — a folyamat hibás.

• Felszínes review — Approve elmélyülés nélkül. Megoldás: ne review-z, ha nincs időd.
• Nitpicking — a linter által ellenőrzött stílus kritikája. Megoldás: automatizáld a style checks-eket.
• Személyes észlelés — "én máshogy írtam volna". Megoldás: a kódnak működnie kell, nem a reviewer tetszését kell elnyernie.
• Elnyújtás — 24 óránál hosszabb review. Megoldás: SLA a review-ra, eszkaláció megsértés esetén.
• Kontextus figyelmen kívül hagyása — kód review a feladat megértése nélkül. Megoldás: olvasd el a PR leírását a diff előtt.