3.4 Hogyan fogadd a review visszajelzést

Áttekintő

A code review legnehezebb részét nem a reviewerek írják – hanem te éled át, amikor a kommenteket olvasod. Egy egyszerű megjegyzés is képes úgy hatni, mintha azt mondanák: „nem vagy elég jó." Ez normális érzés. De ha nem tanulsz meg különbséget tenni a kód kritikája és a személyes kritika között, a code review folyamatosan stressz lesz számodra – és lassabban fejlődsz.

Ebben az alfejezetben megtanulod:

miért sértenek a review kommentek (és miért nem kellene)
mit jelent valójában a „kód ≠ személyiség" elv a gyakorlatban
hogyan reagálj szövegben professzionálisan
mikor fogadd el és mikor vitatkozz egy kommenttel
hogyan tanulj hosszú távon a visszajelzésekből

Miért számít ez az állásinterjún?
Szinte minden interjún elhangzik valami ilyesmi: „Mesélj egy szituációról, amikor kritikát kaptál a munkádra." Ha meg tudod fogalmazni, hogy hogyan kezeled a review visszajelzéseket – hogyan tanulsz belőle, mikor vitatkozol, mikor fogadod el –, az azt mutatja, hogy éretten gondolkodsz a saját fejlődésedről.

Részletes leírás

Miért sértenek a review kommentek?

Az első munkahelyen szinte mindenki ugyanezt éli át: kapod az első review-t, és valami becsíp. Talán egy „ez hibás" komment, talán egy „ezt nem jól gondoltad végig" jellegű megjegyzés. Rosszul esik. Esetleg védekezővé válsz.

Ez teljesen normális – és van pszichológiai magyarázata.

Három fő ok, amiért fájnak a review kommentek:

Sokat dolgoztál rajta. Ha 3 napot töltöttél valamivel, és valaki 5 perc alatt megmondja, hogy mi a baj – az aránytalannak érződik.

Még nem választod szét magad és a kódod. Junior fejlesztőként a kód még nagyon „te" vagy. Ahogy tapasztaltabb leszel, egyre inkább a kódra tudsz tekinteni kívülről – de ez tanult készség.

A szöveg elveszi a hangszínt. Egy szöveges kommentből nem hallja az ember, hogy a reviewer barátságosan mondta-e vagy sem. Az agy sokszor a legrosszabbat feltételezi.

Kód ≠ személyiség – mit jelent ez a gyakorlatban?

Ezt könnyű fejből mondani, nehezebb megélni. Néhány konkrét keret, ami segíthet:

Gondolj így rá: A kódbázis közös tulajdon. Ahogy bekerült a repo-ba, már nem csak a tiéd. A reviewer nem a te munkádat ítéli meg – a csapat közös kódjának minőségét védi.

Kérdezd meg magadtól: Ha egy ismeretlen fejlesztő kódjában látnám ugyanezt a problémát, mit gondolnék? Valószínűleg semmi személyeset – csak azt, hogy „hm, ezt kellene javítani."

Emlékezz: Mindenki kap review kommenteket. A senior fejlesztők is. A legkiválóbb mérnökök is. A review nem azt jelzi, hogy rosszul csináltad a munkádat – azt jelzi, hogy a csapat törődik a kód minőségével.

Hogyan reagálj szövegben?

A review-ra való reagálás is kommunikáció. Ahogy te is igényled, hogy konstruktívan írjanak hozzád, a reviewernek is udvarias és átgondolt választ kell adnod.

Az egyszerű eset: elfogadod a kommentet

Ha a reviewer-nek igaza van, a legrosszabb, amit tehetsz: csendben javítasz és kész. A legjobb:

Köszönöm, jó szem – javítottam.

Igazad van, ezt kihagytam. Megcsináltam.

Miért érdemes válaszolni?

Lezárja a szálat (a reviewer tudja, hogy kezeltéd)
Emberi kapcsolatot épít
Megmutatja, hogy nem automatikusan végzed a munkádat

Ne csak annyit írj: done – ez érzelmileg hideg és semmi kontextust nem ad.

Ha kérdésed van

Ezt a részt nem teljesen értem – pontosan mit kellene másképp csinálni?
Az volt a célom, hogy X-et érjek el, ezt máshogy oldanád meg?

Fontos: Kérdezz, ne védekezz. A különbség:

Védekezés: „Szerintem ez így is jó, mert..."
Kérdés: „Hogyan oldanád meg te ezt az esetet?"

Ha nem értesz egyet

Ez a legfontosabb és legkényesebb eset. Igenis lehet és kell vitatkozni – de profin.

Amit csinálj:

Magyarázd el a gondolatmeneted: miért döntöttél így?
Hivatkozz konkrétumokra: mérés, dokumentáció, korábbi döntés
Kérd a reviewer véleményét az ellenérveidre

Amit ne csinálj:

Ne ignoráld a kommentet
Ne reagálj érzelmi alapon
Ne ess bele az „elvből tartom a véleményemet" csapdájába

Példa konstruktív vitára:

Megértem a felvetést, de itt szándékosan ezt a megközelítést választottam,
mert [konkrét ok]. Látod-e ezzel kapcsolatban problémát? Ha igen, szívesen
megbeszéljük élőben is.

Mikor fogadd el, mikor vitatkozz?

Nem minden kommentre érdemes vitát nyitni. Íme egy egyszerű döntési keret:

Szituáció	Teendő
A reviewer nyilvánvalóan igaza van	Fogadd el, javíts, köszönd meg
Nem érted teljesen	Kérdezz, ne feltételezz
Más megközelítést választottál, de az is működik	Magyarázd el, kérd véleményét
Technikai kérdés, ahol bizonytalan vagy	Fogadd el – a senior tapasztalata értékes
Stílusbeli kérdés (nit szintű)	Általában fogadd el vagy egyezz meg konvencióban
Olyan döntés, ami az architektúrát érinti	Hozd be a csapatot / seniort

Ökölszabály: Ha a vitát az jellemzi, hogy „én-vs-ő" alapon gondolkozol, valószínűleg rossz irányba mész. Ha a vitát az jellemzi, hogy „melyik megoldás jobb a kódbázisnak?", jó úton jársz.

Hosszú távú tanulás a kommentekből

A review kommentek adatbázis. Ha csak javítasz és felejted, a felét kidobod.

Amit profi fejlesztők csinálnak:

Mintákat keresnek. Ha ugyanarra a hibára kapsz kommentet 3 különböző PR-ban, az nem véletlen – ez a tanulási irányod.

Megkérdezik a kontextust. „Miért számít ez fontos?" – ha megértjük a miértet, nem csak a konkrét javítást tanuljuk meg, hanem az elvét.

Visszaellenőrzik a régi kódot. Ha megtanulsz valamit egy review-ból, nézd át a régebbi kódodat: nincs-e ott is ugyanez a minta?

Tudatosítják. Rövid önreflexió: „Ma megtanultam, hogy X esetén Y a jobb megközelítés."

Életszerű példák

Szituáció 1: Az első éles review

Ádám junior fejlesztő, 3 hetes az első munkahelyén. Beadja az első önálló PR-ját. Visszakap 12 kommentet.

Első gondolata: „Ez szörnyű. Semmit sem tudok."

Amire érdemes átváltani: 12 komment = 12 tanulási lehetőség. A reviewer időt szánt arra, hogy segítsen. Ha nem érdekelné, nem írna semmit.

Mit tesz Ádám:

Átolvassa az összeset, mielőtt bármin változtat
A blocker kommenteket kezeli először
Minden kommentre válaszol (akár csak „Köszönöm, javítottam.")
Ha valami nem egyértelmű, kérdez

Szituáció 2: A sértő komment

Kata kap egy review kommentet: „Ez alapvető hiba."

Rossz reakció: Védekezik, visszaszól, vagy csendben javít és haragszik.

Jó reakció:

Javítottam – köszönöm, hogy jelezted. Ha van más ilyen alapvető dolog,
amit érdemes figyelnem, szívesen tanulok belőle.

Miért ez a jó reakció?

Nem vesz részt a negatív dinamikában
Professzionálisnak mutatja Katát
Nyitott marad a tanulásra

Szituáció 3: A vitás komment

Bence egy konkrét algoritmust választott, amit a reviewer másra cserélne. Bence úgy érzi, az ő megoldása jobb ebben az esetben.

Rossz reakció:

Szerintem az enyém is jó.

Jó reakció:

Megértem a javaslatot. Azért választottam ezt a megközelítést, mert
a jelenlegi adathalmazon (kb. 500 elem) a különbség elhanyagolható,
és ez jobban illeszkedik a meglévő kód stílusához. Ha nagyobb adathalmazt
várunk, szívesen váltok – mit gondolsz?

Szituáció 4: Ugyanaz a hiba harmadszor

Dorina harmadik PR-jában is kap kommentet az error handling hiányáról.

Amit Dorina csinál: Ezúttal nem csak javít – megnéz 5 régebbi PR-t, és megnézi, vannak-e ott is hasonló minták. Talál kettőt. Javítja proaktívan és megemlíti a review-ban.

Javítottam az error handling-et itt is. Észrevettem, hogy a korábbi
2 PR-ban is van hasonló – azokat is átfésültem és javítottam.

Ez az a fajta proaktivitás, ami megkülönböztet egy átlagos junort egy kiemelkedőtől.

Feladatok és tesztek

Gyakorlati feladat: Válasz megírása erős kommentre

Írj szakmai, udvarias választ az alábbi 3 szituációra. Minden esetben jelöld, hogy elfogadod-e a kommentet, vitatkozol-e, vagy kérdést teszel fel.

1. feladat:

Review komment:

Ez a megközelítés teljesen rossz. Miért nem használtad az X osztályt?

Kontextus: Az X osztály létezik a codebase-ben, de te nem tudtál róla. A reviewer-nek igaza van.

2. feladat:

Review komment:

nit: Ezt a metódust érdemes lenne két külön metódusra bontani az olvashatóság kedvéért.

Kontextus: Nem értesz egyet – szerinted a jelenlegi 20 soros metódus jól követhető, és a felosztás mesterséges lenne.

3. feladat:

Review komment:

Hiányzik az input validáció.

Kontextus: Nem egyértelmű, mire gondol a reviewer – a frontend már validál, és te azt gondoltad, a backend validáció felesleges duplikáció.

Tesztkérdések

1. kérdés: Egy junior fejlesztő kap egy review kommentet: „Ez alapvető hiba." Mi a legprofesszionálisabb reakció?

a) Szó nélkül javít, hogy minél hamarabb túl legyen rajta
b) Visszaír: „Szerintem nem alapvető hiba."
c) Javít, köszönet jelzést ír, és kérdez, ha nem érti miért hiba
d) Megkérdezi a csapatvezető véleményét a reviewer kommentjéről

2. kérdés: Mit jelent a gyakorlatban a „kód ≠ személyiség" elv?

a) A kódot névtelenül kell beadni, hogy ne tudják, ki írta
b) A review kommentek a kódra vonatkoznak, nem az ember értékére
c) A reviewer ne tudja, ki írta a kódot
d) Minden kódot ugyanolyan szigorral kell megítélni, státusztól függetlenül

3. kérdés: Mikor érdemes vitatkozni egy review kommenttel?

a) Ha a reviewer junior nálad
b) Ha úgy érzed, személyes kritikát fogalmazott meg
c) Ha van konkrét technikai érved a saját megközelítésed mellett
d) Ha a komment több mint 1 mondatos

4. kérdés: Mi a különbség a „done" és egy érdemleges válasz között?

a) A „done" gyorsabb, ami hatékonyabb munkát mutat
b) Az érdemleges válasz kontextust ad, lezárja a szálat, és emberi kapcsolatot épít
c) A „done" azt jelzi, hogy elfogadtad a kritikát
d) Nincs különbség, a reviewer úgyis csak azt nézi, hogy javítottad-e

5. kérdés: Kata harmadszor kap kommentet ugyanarra a hibára különböző PR-okban. Mi a helyes lépés?

a) Elfogadni és javítani, mint eddig
b) Kérni a reviewertől, hogy ne ismételje meg ugyanazt
c) Javítani a hibát, visszanézni a régebbi kódban, és proaktívan jelezni a reviewer felé
d) Elmagyarázni, hogy szándékosan csinálta így

6. kérdés: Miért fájnak különösen az első munkahelyen kapott review kommentek?

a) Mert a reviewerek szándékosan keményebben bírálnak juniorokat
b) Mert a junior még nem választja szét magát és a kódját, és sokat dolgozott rajta
c) Mert a code review folyamat alapvetően hibás rendszer
d) Mert a szöveges kommunikáció mindig félreérthető

7. kérdés: Egy stílusbeli kérdésben (nit szintű) nem értesz egyet a reviewerrel. Mit csinálsz?

a) Elvből nem változtatsz – a nit nem kötelező
b) Megnézed, van-e csapat konvenció, és ha nincs, javasolsz egyet a jövőre
c) Visszaírod, hogy te másképp látod, és lezárod a szálat
d) Elfogadod komment nélkül, hogy gyorsabban mergelhess

8. kérdés: Mi NEM segít abban, hogy hosszú távon tanulj a review kommentekből?

a) Visszanézni a régebbi kódban, hogy nincs-e ott is ugyanaz a minta
b) Megkérdezni a miértet, ha nem érted az elvet
c) Minél gyorsabban javítani és továbblépni a következő feladatra
d) Tudatosítani magadban a tanulságot

9. kérdés: Péter kap egy kommentet, amivel nem ért egyet. Melyik válasz a legmegfelelőbb?

a) „Szerintem az enyém is jó."
b) „Azért döntöttem így, mert X – mit gondolsz erről az érvről?"
c) „Megcsinálom, ha te mondod, de szerintem felesleges."
d) „Megnézem a csapatvezetővel."

10. kérdés: Egy review komment érzelmileg erős hatást vált ki belőled. Mit tegyél először?

a) Azonnal válaszolj, hogy megmutasd, tudsz gyorsan reagálni
b) Ignoráld és javíts csendben
c) Várj, olvass el minden kommentet, majd higgadtan reagálj
d) Kérd meg a reviewert, hogy fogalmazzon udvariasabban

Megoldások (tesztkérdések)

c – Javít, köszönetet jelez, kérdez ha szükséges
b – Review a kódra vonatkozik, nem az ember értékére
c – Konkrét technikai érv esetén érdemes felvetni
b – Érdemleges válasz kontextust ad és emberi kapcsolatot épít
c – Proaktív javítás + jelzés a reviewer felé
b – Nem választja szét magát és a kódját, és sokat dolgozott rajta
b – Csapat konvenciót keres, és ha nincs, javasol egyet
c – Gyors javítás és továbblépés nem segít a hosszú távú tanulásban
b – Konkrét érv + kérdés nyitva tartja a párbeszédet
c – Várj, olvass el mindent, majd higgadtan reagálj