3.1 Mi a code review

← 3. Code review kultúra és készségek

3.1 Mi a code review valójában és miért létezik?

Áttekintő

Sokan azt hiszik, hogy a code review célja a hibák megtalálása. Ez részben igaz – de csak részben. Ha csak erre gondolsz, akkor kimaradsz a code review valódi értékéből.

A code review egy kommunikációs és minőségbiztosítási folyamat, amelynek során egy másik fejlesztő (vagy több) átnézi a te kódodat, mielőtt az bekerül a közös kódbázisba. Az eredmény nem csupán egy „hibamentesebb kód", hanem egy csapat, amelynek tagjai jobban ismerik egymás munkáját, közösen alakítják a kódminőséget, és tanulnak egymástól.

Amit ebből az alfejezetből tanulsz:

  • Mi a code review valódi célja (és mi nem az)
  • Mikor kötelező és mikor opcionális
  • Milyen formái léteznek
  • Hogyan hat a csapat kultúrájára

Részletes leírás

A code review négy célja

1. Minőségbiztosítás
A review megakadályozza, hogy hibás, nem biztonságos vagy nehezen karbantartható kód kerüljön a közös kódbázisba. De ez nem azt jelenti, hogy a reviewer feladata minden apró bug megtalálása – arra ott a tesztelés.

2. Tudásmegosztás
Ha csak te látod a saját kódodat, a csapat többi tagja nem tudja, hogyan oldottad meg a problémát. Review során mindenki megtanulja a megközelítésedet – és te megtanulod az övékét. Ez az egyik legjobb informális tanulási forma egy csapatban.

3. Egységes kódstílus és architektúra
Minden fejlesztőnek megvan a saját stílusa. Code review nélkül hamar olyan kódbázis keletkezik, ahol minden fájl más elvek szerint íródott. A review segít fenntartani az egységességet: naming konvenciók, strukturálás, rétegek szétválasztása.

4. Közös felelősség
Ha valaki reviewolta a kódodat és jóváhagyta, akkor nem csak te vagy felelős érte – a csapat közösen vállal felelősséget. Ez csökkenti a „blame game" kultúrát: nem az a kérdés, hogy ki hibázott, hanem az, hogy mit tanulunk belőle.

Mikor kötelező, mikor opcionális?

A legtöbb komoly tech cégben a code review kötelező minden olyan változtatásnál, ami a fő ágra (main/master/develop) kerül. Ezt általában a Git workflow kényszeríti ki: PR (pull request) nélkül nem lehet merge-elni.

Vannak helyzetek, ahol lazábban kezelik:

  • Hotfix éles rendszeren: sürgős produkciós hiba esetén előfordulhat, hogy gyorsabb a javítás, mint a teljes review folyamat – de utólag mindig érdemes reviewolni
  • Nagyon kis projektek vagy egyszemélyes csapatok: itt nincs kinek reviewolni, de a szokást érdemes kialakítani
  • Spike / proof of concept kód: kísérletező jellegű, eldobandó kód esetén kevésbé kritikus

Junior fejlesztőként számítsd fel, hogy minden PR-odat reviewolni fogják. Ez nem büntetés – ez az egyik legjobb lehetőség a tanulásra.

A code review három formája

1. Formális PR review (pull request review)
Ez a leggyakoribb forma. Megnyitsz egy PR-t, a csapat egy vagy több tagja aszinkron módon átnézi, kommentál, majd jóváhagyja vagy változtatásokat kér. GitHub, GitLab, Bitbucket mind támogatják ezt. Az aszinkron jellege miatt alkalmas remote csapatoknak és különböző időzónákban dolgozóknak.

2. Pair programming
Két fejlesztő egyszerre dolgozik ugyanazon a kódon – az egyik ír (driver), a másik figyel és irányít (navigator). Ez a „live review" formája: a visszajelzés azonnal érkezik, nincs várakozás. Különösen hasznos komplex problémáknál vagy onboarding során, amikor egy junior tanul egy seniortól.

3. Over-the-shoulder review
Informális, alkalmi: odamész a kolléga mellé (vagy megnyitod a screensharet), és együtt nézitek át a kódot. Gyors, de nincs írásos nyoma. Kisebb változtatásoknál vagy sürgős esetekben praktikus.

FormaAszinkron?Dokumentált?Mikor ideális?
PR review✅✅Mindennapos fejlesztés
Pair programming❌❌Komplex feladat, mentoring
Over-the-shoulder❌❌Gyors kérdés, kis változtatás

Hogyan hat a csapatkultúrára?

A code review nem csupán technikai folyamat – szociális folyamat is. Ahogy a csapat reviewol, az tükrözi és alakítja a csapatkultúrát.

Egészséges code review kultúra jegyei:

  • A kommentek a kódról szólnak, nem a személyről
  • A reviewer feltesz kérdéseket, nem csak parancsol
  • A szerző nem védekezik, hanem tanul
  • Pozitív visszajelzés is elhangzik, nem csak kritika
  • A review elvégzése prioritás, nem elmarad napokig

Mérgező code review kultúra jelei:

  • „Miért írtad így ezt a szar kódot?"
  • Mindenki mindenkit blokkol apróságokon
  • A senior jóváhagyása nélkül senki sem mer dönteni
  • PR-ok hetekig nyitva maradnak visszajelzés nélkül
  • A junior fejlesztők félnek PR-t nyitni

Ha az első munkahelyeden mérgező code review kultúrát tapasztalsz, tudd: ez nem normális, és nem te vagy a probléma.

Életszerű példák

1. példa: Az „ez csak egy kis változtatás" csapda

Ádám, junior fejlesztő, kijavít egy apró CSS hibát. Úgy gondolja, „ez akkora semmiség, hogy PR nélkül is mehet". Becommitol mainre. Másnap kiderül, hogy a változtatás elrontott egy más böngészőben tesztelt feature-t, amit a csapat nem vett észre. Ha lett volna PR review, valaki felfedezte volna.

Tanulság: A kis változtatások is megérdemlik a review-t. Nem azért, mert nem bíznak benned, hanem mert négy szem többet lát.

2. példa: A review mint tanulás

Bea, junior fejlesztő, megír egy listaszűrő függvényt. A reviewer, Csaba, jóváhagyja, de hozzáfűzi:

„Ez működik, de érdemes lehet megnézni, hogyan viselkedik 10 000 elemű listánál. Jelenleg O(n²) a komplexitása – nem gond most, de tartsd észben."

Bea nem ismerte ezt a fogalmat. Utánanéz, megérti. Nem kellett kurzust vennie – a napi munkából tanult.

Tanulság: A code review nem csak hibakereső eszköz. Egy jó reviewer tanít is.

3. példa: Over-the-shoulder a valóságban

Dénes, junior, elakad egy API integrációnál. Két óra próbálkozás után megkéri Elvirát, a seniort: „Gyorsan ránéznél?" Öt perc screenshare alatt Elvira megmutat egy kevéssé ismert HTTP fejléc-beállítást, amit Dénes nem ismert. Probléma megoldva.

Ez nem formális review, de ugyanolyan értékes: Dénes tanult, Elvira látta, mi okoz nehézséget a junioroknak.

4. példa: Csapatkultúra különbsége

Csapat A: PR review átlagos ideje: 24-48 óra. Kommentek: kérdések és javaslatok. A senior rendszeresen ír pozitív visszajelzést is. A juniorok bátran nyitnak PR-t kis kísérletekre is.

Csapat B: PR review átlagos ideje: ismeretlen, sokszor napokig senki sem nézi. Ha megnézik, a kommentek kategorikusak: „Ez nem így kell." A juniorok csak akkor nyitnak PR-t, ha már nagyon biztosak.

Mindkét csapatban ugyanolyan emberek dolgoznak. A különbség a kultúrában van – amit a seniorok alakítanak ki, de a juniorok is befolyásolnak.

Tesztfeladatok

1. feladat – Szituáció azonosítás

Az alábbi szituációkban azonosítsd, hogy melyik review-forma lenne a legmegfelelőbb. Indokold a választásodat!

a) Zsófi, junior fejlesztő, egy összetett, 500 soros refactort írt, ami 3 modult érint. A csapat 4 fős, fél remote.

b) Gábor elakadt egy rejtélyes teszthiba megoldásán. A teamlead szabad. Gyors segítséget szeretne, nem írásos reviewt.

c) A csapat bevezet egy új naming konvenciót. Az első PR, ami ezt alkalmazza, referencia lesz a többieknek.

2. feladat – Igaz vagy hamis?

Jelöld meg, hogy az alábbi állítások igazak-e vagy hamisak! Ha hamis, fogalmazd meg a helyes állítást!

  1. A code review elsődleges célja a bugok megtalálása.
  2. Pair programming esetén nem szükséges utólagos PR review.
  3. A code review kultúrát elsősorban a seniorok alakítják, de a juniorok is befolyásolhatják.
  4. Ha valaki jóváhagyta a kódodat, onnantól ő felel az esetleges hibákért.
  5. Over-the-shoulder review nem tekinthető „valódi" code review-nak.

3. feladat – Komment elemzés

Az alábbi code review kommentek közül melyik tükröz egészséges, és melyik mérgező csapatkultúrát? Magyarázd meg a különbséget!

A komment:

„Ez az implementáció működhet, de aggódom a teljesítménye miatt nagyobb adathalmaznál. Véleményem szerint érdemes lenne ezt az esetet megvizsgálni. Mit gondolsz?"

B komment:

„Ezt ki kell dobni és újraírni. Látszik, hogy nem gondoltad végig."

C komment:

„Ezt a megközelítést mi általában nem szoktuk használni – lásd a projekt CONTRIBUTING.md fájlját. Ha kérdésed van, keresz meg."

4. feladat – A négy cél

A code review négy célja: minőségbiztosítás, tudásmegosztás, egységes kódstílus, közös felelősség.

Az alábbi szituációkhoz rendeld hozzá a leginkább érintett célt (egy szituációnál több cél is érintett lehet):

a) A reviewer megtalálja, hogy egy validáció hiányzik a form handlerből.

b) Egy junior fejlesztő a reviewból tanulja meg, hogy a csapat mindig interface mögé rejti a külső service hívásokat.

c) A reviewer jóváhagyja a PR-t, majd három nappal később az a kód okoz produkciós hibát. A retrospektívon mindenki tanulságokat von le – nem egyetlen embert hibáztatnak.

d) A reviewer megjegyzi, hogy a változóneveket az egész projektben angolul szokás írni, nem magyarul.

5. feladat – Mikor kötelező?

Az alábbi szituációkban döntsd el: kötelező-e a code review, opcionális, vagy elfogadható a megkerülése? Indokold a választásodat!

a) Produkciós rendszeren leállt az autentikáció. A bugfix egy soros, de éjjel 2 van és nincs más elérhető fejlesztő.

b) Egy junior fejlesztő egy új feature-t fejleszt, ami az adatbázist módosítja.

c) Egy fejlesztő a saját személyes branchen dolgozik kísérletező jelleggel. Még nem nyit PR-t.

d) Egy szöveg módosul egy gombon: „Mentés" → „Küldés".

6. feladat – Kultúra diagnosztika

Képzeld el, hogy belépesz egy új munkahelyre. Az alábbi jelek közül melyek utalnak egészséges, és melyek mérgező code review kultúrára?

  1. A PR-ok általában 1-2 napon belül választ kapnak.
  2. A seniors fejlesztők ritkán írnak pozitív visszajelzést – „ez a normál, miért dicsérjem?"
  3. A juniorok kis, kísérletező PR-okat is nyitnak, nem csak tökéletes kódot.
  4. Ha egy bug kijut production-be, az első kérdés: „Ki reviewolta ezt?"
  5. A reviewok tartalmaznak kérdéseket, nem csak utasításokat.
  6. A juniorok megkérdezik: „Biztos PR-t nyissak erre? Ilyen kis dolog..."

7. feladat – Összehasonlítás

Egy csapatban ketten is írtatok megoldást ugyanarra a problémára (különböző ágon). Te a te megoldásodat jobbnak tartod. A reviewer inkább a másik fejlesztő megoldását javasolja mergelni.

Hogyan reagálsz? Írd le, mit mondanál a PR kommentben (2-4 mondat).

(Nincs egyetlen helyes válasz – a megközelítés és a hangnem számít.)

8. feladat – Definíció kiegészítés

Egészítsd ki az alábbi mondatokat a helyes szóval/kifejezéssel!

  1. A code review során a PR megnyitójának szerepe a ________, a revieweré a ________.
  2. Ha aszinkron, írásos nyomot hagyó review-t szeretnénk, a ________ forma a megfelelő.
  3. Két fejlesztő egyidejű munkája ugyanazon kódon a ________ neve.
  4. A code review a hibákon túl elsősorban ________ és ________ eszköze.
  5. Ha a reviewer jóváhagyja a kódot, a felelősség ________ marad, nem ________-ra száll át.
Scroll to Top