6.7 „Miért nem találom a hibát?" – mentális csapdák és kiutak

Áttekintő

Volt már olyan, hogy 2 órát töltöttél egy hibán, és semmi? Minden követ megfordítottál, mégis ott van. Aztán eljön egy kollégád, ránéz 5 percig – és megtalálja.

Ez nem arról szól, hogy te rossz vagy. Ez arról szól, hogy az agyad csapdát állít neked. A hosszú hibakeresés nem csak technikai probléma – mentális probléma is. Ebben az alfejezetben azokat a gondolkodási mintákat nézzük meg, amelyek lelassítják a hibakeresést, és azt, hogy hogyan törhetsz ki belőlük.

Amit megtanulsz:

Milyen kognitív torzítások nehezítik a debuggolást
Mikor és hogyan kérj segítséget (és miért nem szégyen)
Konkrét stratégiák, ha elakadtál

Részletes leírás

A confirmation bias – amikor azt keresed, amit várni akarsz

A confirmation bias azt jelenti: az agyad azt a bizonyítékot veszi észre, ami alátámasztja az előzetes feltevésedet – és figyelmen kívül hagyja, ami cáfolja.

Debugging közben ez így néz ki:

„Biztosan az adatbázis kapcsolatban van a hiba" → csak a DB-kapcsolatot nézed → minden más kódot átugrasz → a hiba valójában egy elgépelt változónévben volt, amit 10x megnéztél, de mindig „rendben levőnek" láttál.

Miért veszélyes? Mert az agy aktívan elvégzi a szűrést. Nem véletlenül hagyod ki a szembetűnő hibát – az agyad kiszűri, mert „nem oda kell nézni".

Ellenszer: Minden hipotézis után kérdezd meg magadtól: „Mit kellene látnom, ha NEM itt van a hiba?" Ha nem tudsz válaszolni, nem vizsgálódtál elég széles körben.

Alagút-látás – amikor csak egy helyen keresel

Szorosan kapcsolódik az előzőhöz, de más mechanizmus. Alagút-látás esetén nem az előzetes feltevés a baj, hanem az, hogy a keresési területet önkényesen leszűkíted.

Tipikus juniorhibák:

„Ez a rész az én kódom, itt keresek" → de a hiba az ő kódjával kommunikáló API-ban van
„Ez biztosan frontend probléma" → de a backend hibás adatot ad vissza
„Ez az a sor, ahol az exception dobódik" → de az exception oka 3 réteggel feljebb van

Ellenszer: Rajzold fel (papíron, szövegesen, fejben) a teljes adatfolyamatot a hibás működés előtt és után. Hol kezdődik az eltérés? Az exception helye ≠ a hiba helye.

Fáradtság hatása – amikor az agy már nem lát tisztán

Hosszú debugging session után az agy hatékonysága drámaian csökken. Nem érzed, hogy fáradt vagy – de a kód egyre inkább „ugyanolyannak" tűnik minden sorban.

Ez nem gyengeség – ez biológia.

Konkrét jelek:

Ugyanazokat a sorokat olvasod újra és újra
Hirtelen nem érted, mit csinál egy kód, amit 5 perce még értettél
Minden hipotézis „valószínűnek" tűnik
Elkezdesz véletlenszerűen módosítgatni

Ellenszer: Ha 45-60 percnél tovább debuggolsz egy helyen – állj fel. Igyál vizet, sétálj 5 percet. Nem luxus, hanem hatékonyság.

A friss szem effektus – miért találja meg a kolléga 5 perc alatt

Amikor valakinek elmagyarázod a problémát, két dolog történik:

Kénytelen vagy strukturálni – el kell magyaráznod a kontextust, a feltevéseidet, amit már próbáltál. Ezalatt sokszor magadtól rájössz.
A másik ember nincsenek előzetes feltevései – ő tényleg friss szemmel néz rá, és olyat vesz észre, amit te „tudod, hogy nem az" alapon kizártál.

Ez a jelenség olyan erős, hogy létezik a rubber duck debugging technika: magyarázd el a problémát egy gumi kacsának (vagy bármilyen tárgynak). A strukturált magyarázat kényszere maga oldja meg a problémát.

Ellenszer: Magyarázd el a problémát valakinek – vagy ha nincs senki, egy gumi kacsának, egy noteszbe, hangüzenetként magadnak. Hangosan, sorban, az elejétől.

„Visszatérés az alapokhoz" stratégia

Amikor elakadsz, az ösztön az, hogy még mélyebbre mész, még több kódot nézel, még komplikáltabb hipotéziseket fogalmazol meg. Ez általában rossz irány.

Helyette: menj vissza az alapokhoz.

Konkrétan:

Ellenőrizd az alapfeltevéseket: tényleg az a függvény fut le, amit gondolsz? (Logolj bele.)
Ellenőrizd az inputokat: tényleg azokat az adatokat kapja a függvény, amiket vársz?
Állíts elő egy minimális reprodukálható példát (lásd 6.4-es alfejezet)
Olvasd el újra a hibaüzenetet szó szerint – ne azt olvasd ki belőle, amit várni akarsz

Sok hiba megoldódik azzal, hogy valaki elolvassa a hibaüzenetet, amit 1 óra óta „ismer", és észreveszi, hogy más betűrendet írt, mint gondolta.

Dokumentáció és changelog mint debugging forrás

Ez az egyik legjobban alulhasznált technika juniorok körében.

Ha a kód egyszer működött, de most nem – valami megváltozott. Ez az első kérdés: Mi változott?

Hol keress:

Git log / git blame – mikor változott az a fájl, és ki változtatta?
Changelog / CHANGELOG.md – külső library frissítésekor mi változott?
Dependency release notes – ha frissítettél valamit, mit törhetett el?
Environment változások – új szerver konfiguráció, új environment variable?
Dokumentáció breaking changes – az API, amit használsz, megváltozott?

Junior fejlesztők sokszor 2 órát keresik a hibát a saját kódjukban, miközben egy külső library patch-verziója csendben megváltoztatta a visszatérési formátumát.

Ellenszer: Amikor regresszióval van dolgod (valamit egyszer működött), az első 5 percet töltsd git log-gal, nem kódolvasással.

Mikor kérj segítséget – és miért nem szégyen

A legrosszabb döntés: 4 órán át egyedül küzdeni, mert „nem akarok butának tűnni".

Egy jó ökölszabály: ha 20-30 percnél tovább keresed ugyanazt, kérj segítséget vagy változtass irányt.

A segítségkérés formái (súlyosság szerint):

Rubber duck debugging – magyarázd el magadnak
Keresés dokumentációban, Stack Overflowon – valaki már biztos szembesült ezzel
Kérdezz a csapatban (Slack, chat) – de írj jó kérdést! (lásd 1.3 alfejezet)
Pair debugging – kérd meg, hogy nézzen rá valaki veled együtt
Formális segítségkérés – meetingre / 1:1-re hozod a problémát

A senior fejlesztők nem azért boldogulnak gyorsabban, mert okosabbak. Hanem azért, mert hamarabb ismerik fel, mikor kell segítséget kérni – és ezt gyorsan teszik meg.

Életszerű példák

Példa 1: A confirmation bias csapdája

Léna junior fejlesztő. Az alkalmazásban felhasználói bejelentkezés nem működik. Azt feltételezi: „biztosan a token validáció rontotta el, tegnap nyúlt hozzá valaki."

3 órán át nézi a token validációs kódot. Minden stimmel. Közben nem veszi észre, hogy a bejelentkezési form action URL-jébe egy extra / csúszott be egy refactoring során – a request rossz végpontra megy.

Ha az első 10 percben a Network tabot nyitja meg és megnézi, hova megy a request – azonnal megtalálja.

Tanulság: A hipotézis meghatározza, hol keresel. Ha a hipotézis rossz, feleslegesen keresel.

Példa 2: A friss szem effektus

Bence 90 percig küzd egy Python hibával. Egy lista üres, de szerinte nem kellene üresnek lennie.

Bemegy a kollégájához: „Nézd meg ezt a funkciót, valami furcsa." Elkezdi magyarázni: „Ez a függvény visszaadja az aktív usereket, ha... várj." Megáll. Rájön, hogy a szűrési feltételbe == helyett = lett volna – de Python-ban ez szintaxishiba lett volna, szóval... visszanézi, és látja: a szűrési feltétel fordítva van, aktív helyett az inaktívakat szűri ki.

A kollégája nem szólt semmit. Bence maga oldotta meg, miközben magyarázta.

Tanulság: A hangos gondolkodás önmagában debuggolás.

Példa 3: Changelog mint kulcs

Péter alkalmazása tegnap este még működött. Ma reggel „500 Internal Server Error". Semmi nem változott a kódban.

Elkezdi nézni a saját kódját. 45 perc – semmi.

Aztán eszébe jut: „Várj, az ops csapat futtatott valami frissítést éjjel." Megnézik a deployment logot: a requests Python library frissült 2.28-ről 2.29-re. Gyorsan rákeresnek a changeloge-ra: megváltozott, ahogy a timeout paramétert kezelik. Péter kódja az új verzióban helytelen paraméterrel hívta az API-t.

Tanulság: Ha a kód nem változott, de a viselkedés igen – a kód körüli környezet változott. Ott keress.

Tesztfeladatok

1. feladat – Melyik mentális csapda ez?

Ádám meg van győződve, hogy a hiba az adatbázis lekérdezésben van. 2 óra múlva kiderül: a probléma a frontend JavaScript kódban volt, egy elírás miatt nem ment el a form. Ádám a 2 óra alatt végig csak a backend kódot nézte.

Melyik debugging csapdáról van szó?

a) Rubber duck debugging
b) Alagút-látás
c) Friss szem effektus
d) Changelog keresés

2. feladat – Mi a helyes következő lépés?

40 perce keresel egy hibát. Már kétszer átolvastad ugyanazokat a fájlokat. Kezded nem érteni, amit korábban értettél.

Mi a leghatékonyabb következő lépés?

a) Nézz meg még egy réteggel mélyebbre a kódban
b) Állj fel, sétálj 5 percet, majd térj vissza
c) Írj egy új, hasonló funkciót semmiféle kapcsolathoz nélkül
d) Töröld a módosításaidat és kezdd elölről

3. feladat – Igaz vagy hamis?

Döntsd el, igaz vagy hamis az állítás:

a) Ha egy exception dobódik egy sorban, a hiba mindig abban a sorban van.
b) A fáradtság csökkenti a debugging hatékonyságát, még ha nem is érzed.
c) A rubber duck debugging csak akkor működik, ha a kacsa válaszol.
d) Ha a kód tegnap működött és ma nem, valami megváltozott a kód körül is.
e) Senior fejlesztők sosem kérnek segítséget.

4. feladat – Sorba rendezés

A következő debugging lépések összekeveredtek. Rendezd sorba logikus sorrendben, ha elakadtál egy hibánál (20+ perc eltelt):

A) Nézd meg a git log-ot, mi változott az érintett fájlokban
B) Magyarázd el a problémát hangosan (rubber duck)
C) Állj meg, és kérdezd meg: mi volt az utolsó dolog, ami biztosan működött?
D) Kérj segítséget egy kollégától strukturált kérdéssel
E) Ellenőrizd az alapfeltevéseket: tényleg azokat az adatokat kapod, amiket gondolsz?

5. feladat – Melyik a legjobb reakció?

Máté 25 perce keresi a hibát. Van egy hipotézise (a session kezelés), és aszerint keresi. Mi a legjobb következő lépés?

a) Maradjon a hipotézisnél, csak nézzen meg még több fájlt
b) Kérdezze meg magát: „Mit látnék, ha NEM a session kezelés a probléma?" – és nézzen arra is
c) Azonnal kérjen segítséget, ne pazarolja tovább az idejét
d) Törölje az összes session-kezelő kódot és írja újra

6. feladat – Hibadiagnózis

Nóra alkalmazása tegnap este jól működött. Ma reggel az API hívások 401 Unauthorized hibával térnek vissza. Nóra nem változtatott semmit a kódban.

Melyik forrást érdemes elsőként ellenőrizni?

a) A saját authentikációs logikáját, hátha van benne bug
b) A git log-ot és a deployment naplót – mi változott a szerveren?
c) A frontend CSS-t, mert valami biztosan ott romlott el
d) A böngésző cache-t, hátha az okozza

7. feladat – A rubber duck módszer

Miért működik a rubber duck debugging? (Jelölj minden helyes választ!)

a) A kacsa valóban megérti a kódot és segít
b) A magyarázat közben strukturálni kell a gondolatokat, ami segít megtalálni a hibát
c) A hangos gondolkodás kényszere leleplezi a hiányos logikát
d) Mert a kacsák mágnesesen vonzzák a bugokat
e) A más nézetből (magyarázó nézőpontból) való gondolkodás megtöri az alagút-látást

8. feladat – Mikor kérj segítséget?

Melyik állítás fejezi ki legjobban a helyes hozzáállást?

a) Sosem kérj segítséget – a senior fejlesztők sosem tesznek ilyet
b) 20-30 perc elteltével, ha nincs áttörés, kérj segítséget vagy változtass stratégián
c) Azonnal kérj segítséget minden hibánál, mert az időd értékes
d) Csak akkor kérj segítséget, ha már 4+ óra eltelt

9. feladat – Elemzés

Olvasd el ezt a hibakeresési szituációt, és azonosítsd, melyik csapda(ák) vannak jelen:

Kata egy hiba miatt keresgél. Azt mondja magának: „Ez biztosan az a rész, amit tegnap módosítottam." 1,5 óra múlva még mindig csak azt a kódrészletet nézi. Nem ellenőrizte a logokat, nem nézte meg a külső API válaszát, nem kérdezett senkit. Egyre fáradtabb, de nem veszi észre, mert „közel van a megoldáshoz".

Azonosítsd az összes mentális csapdát, amit látod!

10. feladat – Saját döntési fa

Készítsd el a saját debugging döntési fádat! A következő pontokat szerepeljenek benne:

Mi a teendő az első 10 percben?
Mi a teendő 30 perc után, ha nincs áttörés?
Mi a teendő 60 perc után?
Milyen forrásokat ellenőrizz regressziógyanús esetben?
Mikor és hogyan kérj segítséget?

(Nem kell kódot írni – elegendő néhány mondatos leírás vagy bullet pont formátum.)

Összefoglalás

A debugging leggyakoribb akadálya nem a tudáshiány – hanem az, ahogy az agyunk működik hosszú keresés alatt. A confirmation bias, az alagút-látás és a fáradtság mind olyan mechanizmusok, amik ellen tudatosan kell védekezni.

A legjobb eszközeid:

Kérdezd meg: „Mit látnék, ha a hipotézisem téves?"
Térképezd fel a teljes adatfolyamatot, ne csak a gyanús részt
Térj vissza az alapokhoz: ellenőrizd az inputokat, a feltevéseket
Magyarázd el hangosan – a gumi kacsának is
Nézd meg a git log-ot és a changelogokat regresszió esetén
Kérj segítséget időben – 30 perc után, ha nincs áttörés

A senior fejlesztő nem azért gyorsabb, mert nem akad el. Hanem azért, mert hamarabb ismeri fel, mikor kell irányt váltani.