1.5 Visszajelzés adása és fogadása – nem személyes támadás

Áttekintő

A visszajelzés – különösen a kritika – az a terület, ahol a legtöbb junior fejlesztő megakad az első munkahelyén. Nem a kód a probléma. Nem a tudás. Hanem az, hogy a code review komment, amit egy senior kolléga írt, valahogy úgy érkezik, mintha a személyiségedet bírálnák, nem a kódodat.

Ez az alfejezet arról szól, hogyan adj és fogadj visszajelzést úgy, hogy az segítsen, ne romboljon. Mert a visszajelzés a csapatmunka egyik legfontosabb eszköze – és ha rosszul csináljuk, mindenki rosszabbul jár.

Amit megtanulsz:

Hogyan fogadj kritikát anélkül, hogy dühös leszel vagy összeomlasz
Hogyan adj konstruktív visszajelzést, amit a másik fél szívesen fogad
Mi az a „sandwich módszer" és miért buktatja el magát
Hogyan különböztesd meg a viselkedésre irányuló kritikát a személyre irányulótól
Mit csinálj code review elutasítás és kemény komment esetén

Részletes leírás

A kód nem te vagy

Az első és legfontosabb mentális váltás: a kódod nem azonos veled.

Ha valaki azt írja a PR-odra, hogy „ez a megközelítés nem jó, inkább csináljuk X-szel" – az nem azt jelenti, hogy te nem vagy jó. Azt jelenti, hogy megtaláltak egy jobb megoldást arra a problémára.

Ez egyszerűen hangzik, de a valóságban nagyon nehéz. Különösen akkor, ha:

Sokat dolgoztál a kódon
Nem vagy biztos magadban (imposter syndrome)
A visszajelzés hangvétele kemény

A jó hír: ez tanulható. Mindenki rosszul érzi magát az első néhány critical review-nál. Idővel pedig megszokod – sőt, értékelni fogod, mert tudod, hogy a reviewed kód jobb lesz, mint az eredeti.

Visszajelzés fogadása

Mit NE csinálj

❌ Ne védekezz azonnal. Ha az első reakciód „de én azért tettem mert...", várj. Olvasd el a kommentet kétszer.

❌ Ne vedd személyesnek a szöveg hangneme miatt. Sokan írnak tömören, hogy időt spóroljanak – ez nem durvaság, hanem hatékonyság.

❌ Ne hallgass el. A legelterjedtebb hiba: nem válaszolsz a kommentekre, csak csendben „megcsinálod". Ez bizonytalanságot okoz a reviewernek (megértette? nem értette meg? elveszett?).

❌ Ne fogadd el vakon, amit nem értesz. Ha egy komment nem egyértelmű, kérdezz rá. „Megértem a problémát, de mi lenne az ideális megközelítés?" teljesen normális kérdés.

Mit csinálj helyette

✅ Reagálj minden kommentre. Egy „Done" vagy „Fixed in latest commit" sokat jelent. A reviewer tudja, hogy dolgoztál rajta.

✅ Ha nem értesz egyet, mondd el – de indokold. „Én X megközelítést választottam, mert Y. Ha van jobb út, szívesen váltok, de szeretném megérteni, mi a probléma az enyémmel." Ez nem arrogancia, hanem szakmai párbeszéd.

✅ Kérdezz, ha nem érted. „Mit értesz ez alatt?" teljesen rendben van. Senki sem vár tőled mindentudást.

✅ Tanulj a kommentekből hosszú távon. Vezess egy egyszerű listát: „Ezt a hibát elkövettem, a következő PR-ban figyelek rá." Egy hónap után meglepődsz, mennyit fejlődsz.

Visszajelzés adása

A konstruktív visszajelzés alapjai

Jó visszajelzést adni is nehéz – és ez sem veleszületett képesség. A legtöbb senior fejlesztő is évekig tanulta.

Négy alapelv:

A kódra fókuszálj, ne a személyre.

❌ „Ezt rosszul csináltad."
✅ „Ez a rész egy edge case-t nem kezel le: mi történik, ha input null?"

Kérdés vs. utasítás.

Nem kell mindig direktívaként fogalmazni. A kérdés kevésbé konfrontatív, és lehet, hogy a szerző tud valami olyat, amit te nem.
❌ „Ezt át kell írni X-re."
✅ „Gondoltál arra, mi történik X esetén? Esetleg X megközelítés segíthet itt."

Blocker vagy javaslat?

Nem minden komment egyforma. Különböztesd meg:
Blocker: Ez a hiba van, nem mergelhető így. Pl.: SQL injection kockázat, nem működő logika.
Javaslat (nit): Ennél jobb lenne, de nem kritikus. Pl.: jobb változónév, kisebb refaktor.
A nit: előtagot érdemes kiírni: nit: ez a változónév félrevezető lehet, mit szólnál az X-hez?

Pozitív visszajelzés is számít.

Ha valami jól van megcsinálva, mondd el. „Jó megközelítés ezt így szétbontani" – ez nem üres bók, hanem megerősítés és tanulás.

A „sandwich módszer" és miért buktatja el magát

Talán hallottál a „feedback sandwich" technikáról: pozitív → negatív → pozitív. Az elmélet szerint a kritika könnyebben megy le, ha édességgel van körülvéve.

A valóságban: ez általában nem működik fejlesztői környezetben.

Miért?

A fogadó fél megtanulja kiszűrni. Tudja, hogy a közepe az igazi üzenet.
A pozitív rész hiteltelennek tűnik, ha csak „csomagolás".
Code review-ban a tömör és egyenes kommunikáció értékesebb, mint a tapintatos kerülőút.

Ami tényleg működik: Legyen a visszajelzés konkrét, kódra fókuszált, és ha lehetséges, javaslat is legyen benne. Nem kell szépíteni – de az udvariatlanságot sem kell „hatékonyságnak" becsomagolni.

Viselkedés vs. személy

Ez az egyik legfontosabb különbség:

Személyre irányuló (kerülendő)	Viselkedésre irányuló (jó)
„Te sosem figyelsz a hibakezelésre."	„Ebben a részben hiányzik a hibakezelés – mi a szándék null esetén?"
„Megint rosszul becsülted az időt."	„Ez a feladat nagyobb lett, mint vártuk – mit lehetett volna jelezni hamarabb?"
„Nem érted, mit csinálsz."	„Ezzel a megközelítéssel van egy probléma: X esetén Y fog történni."

A különbség egyszerű: a viselkedés megváltoztatható; a személy megítélése bántó és haszontalan.

PR elutasítás kezelése

A PR elutasítás (request changes, vagy szélsőséges esetben „ez az irány nem jó, kezdd újra") az egyik legrosszabb érzés juniorként.

Mit ne gondolj:

Hogy te vagy a probléma
Hogy „nem vagyok elég jó ide"
Hogy ezentúl mindig engedélyt kell kérned, mielőtt bármit csinálsz

Mit gondolj helyette:

Ebből a legtöbbet tanulom – mert valaki időt fordított rá, hogy megmagyarázza
Mi az, amit másképp kell csinálnom legközelebb?
Van-e minta a visszajelzésekben, amit nem vettem észre?

Ha a PR-t teljesen visszadobják, kérj egy rövid megbeszélést. „Szeretném megérteni, hol tévedtem irányt" – ez a legproduktívabb kérdés.

Életszerű példák

1. példa: Code review komment fogadása

Szituáció: Megírted az első feature-ödet. A senior reviewer ezt írja:

"This function does too many things. Extract the validation logic."

Rossz reakció: Átírja a kódot anélkül, hogy értené miért, és csak annyit válaszol: „Done."

Jó reakció:

„Megértem a problémát. Kivontam a validációt egy külön validateInput() függvénybe. Jól értelmeztem a szándékot?"

Ez megmutatja, hogy nem csak mechanikusan végrehajtja a kérést, hanem érti is.

2. példa: Konstruktív visszajelzés adása

Szituáció: Reviewolsz egy kollégád kódját és látod, hogy nincs hibakezelés egy API hívás körül.

Rossz komment:

„Nincs hibakezelés."

Jó komment:

„Ha ez az API hívás hibát ad vissza (pl. timeout vagy 500), az alkalmazás elszáll. Mi a szándék hálózati hiba esetén? Talán érdemes try-catch-et vagy egy fallback értéket hozzáadni."

3. példa: Nem értesz egyet a visszajelzéssel

Szituáció: A reviewer azt javasolja, hogy refaktoráld át X-re, de te tudod, hogy az a megközelítés nem fog működni az itteni rendszerben.

Rossz reakció: Csendben átírja (és elveszti az eredeti megközelítés indokát), vagy csendben figyelmen kívül hagyja.

Jó reakció:

„Megértem a javaslatot. Nálunk az X megközelítés nem fog működni, mert [ok]. Esetleg Y lenne egy jó kompromisszum? Nyitok vagyok más ötletre is."

Ez szakmai párbeszéd, nem védekezés.

4. példa: Kemény hangvételű komment

Szituáció: A reviewer ezt írja:

„Ez teljesen felesleges komplexitás. Miért csináltad így?"

Rossz reakció: Védekező, személyesnek érzi, nem válaszol, vagy rosszul érzi magát napokig.

Jó reakció (gondolatban): Ez kemény megfogalmazás, de a tartalom jogos lehet. Miért csináltam így? Van valódi indokom, vagy tényleg overcomplicated?

Jó reakció (szövegben):

„Azért választottam ezt az utat, mert [ok]. Látom, hogy komplex lett. Mi lenne az egyszerűbb megközelítés?"

Tesztfeladatok

1. feladat – Visszajelzés értékelése

Az alábbi code review kommentek közül melyik a konstruktív, melyik a demotiváló? Indokold a választásodat.

A) „Ez a változónév nem egyértelmű."

B) „data egy rossz változónév – mi az, amit tárol? Pl. userProfileData egyértelműbb lenne."

C) „Megint nem teszteltél."

D) „Ehhez a funkcióhoz hiányoznak a tesztek – különösen a null input esetre érdemes lenne egy unit teszt."

2. feladat – Átfogalmazás

Írd át az alábbi agresszív vagy passzív kommentet konstruktív, udvarias formára:

„Ez az egész logika rossz. Teljesen másképpen kell megcsinálni."

3. feladat – Reakció megválasztása

Szituáció: A reviewered ezt írja a PR-odra:

„nit: a getUserData függvény neve félrevezető, inkább fetchUserProfile legyen."

Melyik a legjobb válasz?

A) Nem reagálsz, csak átnevezed.
B) „Átneveztem – köszönöm a javaslatot!"
C) „Nem értek egyet, a getUserData teljesen egyértelmű."
D) „Megértem, de az egész codebase-ben getX konvenciót használunk – konzisztens maradjak, vagy itt kivételt tegyünk?"

4. feladat – Viselkedés vs. személy

Melyik visszajelzés irányul viselkedésre, melyik személyre? Hogyan fogalmaznád át a személyre irányulót?

A) „Mindig elfelejted a hibakezelést."

B) „Ebben a függvényben hiányzik a hibakezelés a DB hívás körül."

C) „Nem gondolkodsz előre."

D) „Ez a megközelítés nem kezeli le azt az esetet, ha a felhasználó nincs bejelentkezve."

5. feladat – Sandwich módszer

Egy kolléga azt mondja: „Mindig sandwich módszerrel adok visszajelzést, mert így nem sért." Mikor lehet ez hasznos, és mikor nem? Írj egy-egy szituációt, ahol érdemes és ahol nem érdemes alkalmazni.

6. feladat – Nem értesz egyet

Kaptál egy review kommentet, amivel nem értesz egyet. A reviewer azt javasolja, hogy az adatbázis lekérdezést tedd a controlleren belülre, de te tudod, hogy ez megsérti a projektben alkalmazott layered architecture elvét.

Hogyan válaszolnál? Írj egy konkrét üzenetet.

7. feladat – PR elutasítás

A PR-odat elutasítják azzal, hogy „ez az irány nem jó, a feature-t másképp kell megközelíteni." Nem kaptál részletes magyarázatot.

Mi a legjobb következő lépés?

A) Megcsinálod újra, ahogy szerinted jó.
B) Megkérdezed: „Miben hibázott a megközelítésem?"
C) Megkérdezed: „Hogyan csináljam?"
D) Megkérdezed: „Kaphatok 15 percet, hogy megértsem, hol tért el az irányom?"

Miért jobb B és D, mint A és C?

8. feladat – Összefoglalás

Listázz legalább 3 konkrét dolgot, amit a jövőben másképp csinálsz visszajelzés fogadásánál vagy adásánál az ebben az alfejezetben tanultak alapján.