3.6 Junior review senioroknak

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

3.6 Junior review senioroknak – merj visszajelzést adni

Áttekintő

Szabad junior fejlesztőnek reviewolni egy senior kódját? A legtöbb junior azt gondolja: nem. Félnek, hogy tudatlannak tűnnek, vagy hogy megsértik a seniort. Ez a félelem érthető – de téves.

A code review nem rangsor alapú tevékenység. Nem a hierarchiáról szól, hanem a kód minőségéről. Egy senior kódja is tartalmazhat hibát, ondolatlan edge case-t, vagy olyat, ami neked – friss szemmel – nem egyértelmű. És pontosan ez az, amit egy jó csapat elvár tőled.

Ebben az alfejezetben megtanulod, miért értékes a junior szempontja egy review-ban, hogyan fogalmazz meg észrevételt úgy, hogy az kérdező és nem kritizáló legyen, és mit nyersz hosszú távon, ha rendszeresen részt veszel a review folyamatban.

Részletes leírás

Szabad junior fejlesztőnek reviewolni senior kódját?

Igen. Sőt: elvárják.

A legtöbb csapatban a code review kétirányú. Nem csak a senior reviewolja a junior PR-ját – minden csapattag minden más csapattag kódját nézheti. Ez nem hierarchia kérdése, hanem tudásmegosztás.

Ha te soha nem reviewolsz senior kódot, az következmény nélküli passzivitás. Nem fejlődsz, nem tanulsz a kódból, és a csapatnak is kevesebbet adsz, mint amit adhatsz.

Miért értékes a junior szempontja?

  • Friss szem effektus. A senior, aki egy rendszert hosszú ideje ismer, vakon lát bizonyos részeket. Te nem. Ha valami nem egyértelmű számodra, az esélyes, hogy hat hónap múlva sem lesz egyértelmű – és ez a kódban probléma.
  • Kérdezéssel is segítesz. Egy kérdező komment – „Ezt a részt nem egészen értem, meg tudod magyarázni miért így?" – arra kényszeríti a szerzőt, hogy újragondolja, vajon egyértelmű-e a logika.
  • Elírásokat, typo-kat, hiányzó dokumentációt te is észreveszel. Ez nem senior-junior kérdés.

A hangneme: kérdés vs. kritika

Ez a legfontosabb különbség, amit meg kell értened.

Kritika hangnemben írni valakiről, aki tapasztaltabb nálad, szinte biztosan rossz végeredményt ad. Nem azért, mert a kritika rossz dolog – hanem mert pozíció nélkül, kontextus nélkül, egy junior szájából sértőnek hat még akkor is, ha igaz.

Kérdező hangnemben viszont ugyanazt az észrevételt el lehet mondani úgy, hogy az konstruktív, nyitott és fejlesztő hatású. Nem ítélkezik, hanem párbeszédet nyit.

Ugyanaz a megfigyelés, kétféle hangnemben:

Kritika hangnemKérdező hangnem
„Ez az algoritmus O(n²), ami elég lassú."„Helyesen értelmezem, hogy ez O(n²) komplexitású? Nagy listáknál teljesítmény probléma lehet?"
„Nincs hibakezelés, ha a DB lekérdezés fail-el."„Mi történik, ha ez a lekérdezés hibával tér vissza – van ennek valahol máshol hibakezelése, amit nem látok?"
„Ez a változónév nem mond semmit."„A d változóra – mit tárol pontosan? Nem sikerült kitalálnom a kontextusból."
„Miért nem használtál egyszerűbb megoldást?"„Kíváncsi vagyok, miért ezt a megközelítést választottad – van-e valami amit ezzel el akartál kerülni?"

Figyeld meg: a kérdező változat ugyanazt a megfigyelést hordozza, de feltételezi, hogy a seniornak lehet oka valamire, amit te nem látsz. Ez az alap.

Mikor írj kommentet, mikor ne?

Írj kommentet, ha:

  • Valami nem egyértelmű számodra, és valószínűleg másoknak sem lesz az.
  • Potenciális hibát látsz (edge case, NULL kezelés hiánya, typo).
  • Dokumentáció hiányzik egy komplex részről.
  • Logikai ellentmondást látsz az acceptance criteria és az implementáció között.
  • Olyasmit látsz, amit nem értesz, és tudni szeretnéd miért van úgy.

Ne írj kommentet, ha:

  • Csak a stílused más lenne, és nincs technikai oka a preferenciádnak.
  • Biztosan tudod, hogy a megoldás opcionális döntés és nem hiba.
  • A kommentedet nem tudod kérdező formában megfogalmazni anélkül, hogy ne tűnjön erőltetettnek.

Minőség > mennyiség. Egy jó kérdező komment többet ér, mint tíz apró megjegyzés.

Mit nyersz azzal, ha rendszeresen reviewolsz?

Ez talán a legfontosabb rész, mert a motiváció kérdése.

1. Tanulsz mások kódolási stílusából.
Egy senior kódja tele van döntésekkel: miért ezt az adatstruktúrát, miért ezt a hibakezelési stratégiát, miért így szervezi a fájlokat. Ha csak a saját kóddal foglalkozol, ezeket nem látod.

2. A kérdező komment a leggyorsabb tanulási módszer.
Ha megkérdezed, miért van valami úgy – és kapsz rá választ – azonnal megérted azt a döntést. Ez jobb, mint ha utólag olvasgatnád a Git historyt.

3. Láthatóvá válsz a csapatban.
Egy junior, aki aktívan részt vesz a review folyamatban, nem csak „az a junior aki kódot ír". Ő az, aki törődik a minőséggel. Ez karrierszempontból is számít.

4. Felgyorsítja az onboardingot ismeretlen kódban.
Ha review-n átnézel egy részt, amit korábban nem ismertél, rövidül az az idő, amíg az egész codebase ismerőssé válik.

Hogyan fogadd a reakciót?

Ha kérdező kommentet írsz, háromféle válasz jöhet:

1. Magyarázat: „Azért, mert X – a projekt X korlátja miatt volt így." → Tanultál valamit.
2. Módosítás: „Igazad van, javítom." → Hozzájárultál a kód minőségéhez.
3. Semleges visszajelzés: „Ez szándékos, de jó megfigyelés." → Láttad, visszajelezted, ez volt a cél.

Ha a senior türelmetlenül reagál egy jól megírt, kérdező kommentre – az a csapatkultúra problémája, nem a tied. Egy egészséges csapatban minden review kommentet komolyan vesznek, forrástól függetlenül.

Életszerű példák

1. példa: Az ismeretlen változó

Péter, junior fejlesztő, átnéz egy backend PR-t. Talál egy részletet:

def process(q, d, f):
    if f:
        return q * d
    return q

Péter nem érti, mit jelent q, d, f. Ahelyett, hogy azt írná: „Ezek a változónevek értelmetlenek" – ezt írja:

Kérdező komment: „A q, d, f paraméterekre – meg tudod mondani, mire utalnak? Nem sikerült kitalálnom a kontextusból, és egy rövidebb névvel nehezebb lesz ezt a függvényt jövőre is értelmezni."

A senior megnézi, rájön, hogy igaza van Péternek, és átnevezi a paramétereket quantity, discount, free_shipping-re. Ez mindenki számára jobb lesz.

2. példa: A látszólag hiányzó hibakezelés

Anna reviewolja a senior kollégája JavaScript PR-ját. Egy aszinkron adatbázis-hívást lát:

const user = await db.findUser(userId);
return user.profile;

Anna nem biztos benne, hogy hibakezelés szükséges-e, de gyanakszik. Ezt írja:

Kérdező komment: „Ha findUser nem talál felhasználót és null-t ad vissza, akkor user.profile TypeError-t dob. Van ennek valahol máshol kezelése, amit nem látok, vagy érdemes lenne itt is hozzáadni?"

A senior megnézi – valóban hiányzik a null-check. Megköszöni, javítja.

3. példa: A stílus vs. technikai kérdés

Bálint látja, hogy a senior for-ciklust használ ott, ahol ő map()-et használna. De bizonytalan: van-e technikai oka? Ezt írja:

Kérdező komment: „Kíváncsi vagyok, miért választottad a for-ciklust map() helyett erre a transzformációra – tudatosan, pl. teljesítmény vagy olvashatóság miatt, vagy bármelyik megfelelne?"

A senior válasza: „Nincs technikai oka, map() ott is megfelelne. Szokásból írtam így." → Tanulság: néha nincs döntő ok. Ő is tanult belőle.

Tesztfeladatok

1. feladat – Komment átírás

Az alábbi kommentet írta egy junior egy senior PR-jára. Írd át kérdező, nem ítélkező formában:

Eredeti: „Ez a megközelítés skálázatlan, production környezetben nem fog működni."

2. feladat – Komment vagy nem komment?

Döntsd el, hogy az alábbi szituációkban érdemes-e kommentet írni, és ha igen, milyen hangnemben:

a) Látod, hogy a senior pontosvesszőt hagyott ki ott, ahol az opcionális a nyelvben.
b) Szerinted más algoritmus jobb lenne, de nem vagy biztos benne miért.
c) Egy függvény 120 soros, és nem érted, mit csinál a 80-100. sor.
d) A változónév helyesírása helytelen (egy szó el van gépelve).
e) A senior más zárójel-stílust használ, mint a codebase többi része.

3. feladat – Komment megírása

Az alábbi kódrészletet reviewolod. Írj egy kérdező kommentet az általad azonosított problémára:

function getUserData($id) {
    $result = $db->query("SELECT * FROM users WHERE id = $id");
    return $result->fetch();
}

(Tipp: Mi lehet a biztonsági kockázat? Hogyan kérdezd meg úgy, hogy nem feltételezed, hogy a senior nem tudja?)

4. feladat – Reakció értékelése

Márk junior reviewolja Anna senior kódját, és kérdező kommentet ír egy edge case-re. Anna így válaszol:

„Ezt ne kommenteld, junior vagy, még nem érted a rendszer kontextusát."

Melyik a helyes értelmezés?

a) Márknak igaza lehet volt az észrevétele, de rosszul fejezte ki magát.
b) Anna válasza elfogadható, mert a senior jobban ismeri a kódot.
c) Márk kérdező kommentje jogos volt, Anna reakciója a csapatkultúra problémája.
d) Márk többé ne reviewoljon senior kódot.

5. feladat – Mi a haszna?

Sorold fel legalább 3 konkrét előnyét annak, ha egy junior rendszeresen reviewolja senior kollégái kódjait is – ne csak a saját kódját javítja.

6. feladat – Igaz vagy hamis?

Döntsd el, igaz vagy hamis az alábbi állítás, és indokold meg egy mondattal:

a) „Juniornak csak akkor szabad kommentet írnia senior PR-jára, ha biztosan hibát talált."
b) „Egy kérdező komment akkor is hasznos, ha a válasz az, hogy 'ez szándékos'."
c) „Ha a senior nem reagál a kommentemre, az azt jelenti, hogy hibáztam."
d) „A friss szem perspektíva a junior egyik legértékesebb hozzájárulása review során."
e) „Senior kódot reviewolni azt jelenti, hogy a juniort egyenrangúnak tekintik."

7. feladat – Teljes review komment megírása

Az alábbi Python kódrészletet reviewolod. Írj 2-3 kérdező kommentet, amelyek az észrevételeidet tartalmazzák – kérdező, nem ítélkező stílusban:

import time

def get_users_with_orders():
    users = db.query("SELECT * FROM users")
    result = []
    for user in users:
        orders = db.query(f"SELECT * FROM orders WHERE user_id = {user['id']}")
        result.append({
            "user": user,
            "orders": orders
        })
    time.sleep(0.1)  # small delay
    return result

(Gondolkodj el: N+1 query probléma, SQL injection kockázat, ismeretlen sleep – mindegyikre kérdező komment írható.)

8. feladat – Szituáció: mit teszel?

Péter 3 hónapja dolgozik a csapatban. Megnéz egy PR-t, amelyet a legseniorabb fejlesztő (8 év tapasztalat) nyitott. Péter egy potenciális hibát lát – de nem 100%-ban biztos benne, és fél, hogy rossz.

Melyik a helyes cselekvés?

a) Nem kommentál, mert valószínűleg a senior tudja, mit csinál.
b) Privátban megkérdezi a seniort Slack-en, hogy ne tűnjön ki.
c) Kérdező kommentet ír a PR-ba, jelezve, hogy nem biztos benne.
d) Megvárja, amíg egy másik senior is megnézi, és utána kommentál.

9. feladat – Fogalmi tisztázás

Mi a különbség az alábbiak között? Fogalmazd meg saját szavaiddal (2-3 mondat mindegyiknél):

a) Kérdező komment vs. kritizáló komment
b) Technikai észrevétel vs. stílus-preferencia
c) Komment amit feltétlenül meg kell nézni vs. nit (minor megjegyzés)

10. feladat (bónusz) – Saját komment írása valós kódra

Nézz meg egy nyílt forráskódú projektet (pl. GitHub-on), találj egy PR-t, és írj 1-2 valódi kérdező kommentet, amelyeket el is tudnál küldeni. (Nem kell ténylegesen elküldened – de legyen olyan, amitől nem szegyellnél.)

Szempontok, amin érdemes gondolkodni:

  • Érthetőség (megérted a kódot?)
  • Potenciális edge case-ek
  • Dokumentáció hiánya
  • Változónevek egyértelműsége

Összefoglalás

  • Junior is reviewolhat senior kódot – ez elvárás, nem kivétel.
  • A kérdező hangnem az egyetlen helyes megközelítés: nem ítélkezni, hanem megérteni és párbeszédet nyitni.
  • Friss szem perspektívád értékes – amit te nem értesz, mások sem fogják.
  • Rendszeres review részvétel felgyorsítja a tanulást, láthatóvá tesz, és a csapat minőségéhez járul hozzá.
  • Ha jogos, kérdező kommentet kapsz vissza negatívan – az csapatkultúra kérdése, nem a tiéd.
Scroll to Top