ugrás a tartalomhoz

Egyszerű hibakeresés

Hidvégi Gábor · 2012. Feb. 4. (Szo), 17.30

A Weblaboron előforduló fórumtémák nagy többségénél az a probléma, hogy a szerző csak nemrég kezdett el ismerkedni a webfejlesztéssel, és nem tudja, milyen eszközök állnak rendelkezésre a hibák kiderítéséhez. Ezért igyekszem a legegyszerűbb eszközöket bemutatni, ami a kezdéshez elegendő lesz; ezeknél persze léteznek bonyolultabb módszerek, de azok megtalálását a nyájas olvasóra és a lelkes kommentelőkre bízom.

Kezdő vagyok, merre induljak el?

Emberek vagyunk, tévedhetünk, és gyakran élünk is ezzel a lehetőséggel. Amikor elkezdünk dolgozni egy weboldalon, előbb-utóbb szembesülünk azzal a problémával, hogy nem úgy jelenik az meg, ahogy elképzeltük. Mivel csak pár kósza bitről van szó, a legfontosabb, hogy ne essünk pánikba, hanem a lehetőségek számbavételével izoláljuk a problémát. Nagy segítség ilyenkor, ha modulárisan építkezünk: külön fájlban van a HTML kód, a kinézetért felelő stílusok, valamint a funkcionalitást biztosító JavaScriptek. A megoldáshoz felhasználhatjuk tapasztalatainkat, vagy megkérhetünk másokat, hogy segítsenek, ehhez viszont szükséges, hogy meg tudjuk fogalmazni, hogy mi a gond.

Ehhez az egyik legfontosabb, hogy tanuljunk meg angolul, mert az interneten található ingyenes dokumentációk általában ezen a nyelven íródtak. A számítástechnika kb. 2-3000 szót használ, tehát minimális erőfeszítéssel, gyakorlatilag pár hét alatt belejön bárki, aki komolyan gondolja, hogy el szeretne érni valamit, és talál egy jó szótárat.

A nyelvet célszerű mindjárt az általunk használni kívánt nyelv dokumentációján gyakorolni. Mindenkinek megvannak a saját tanulási szokásai, én általában úgy szoktam kezdeni, hogy végignézem az elérhető összes parancsot-lehetőséget, ami kezdetnek kicsit tömény lehet, de legalább kapok egy képet, hogy mit lehet megvalósítani s mit nem. Magasszintű programozási nyelveknél, mint például a PHP, a függvénynevek szerencsére elég beszédesek ahhoz, hogy rájöjjünk, mire is jó az adott funkció. A nyelvi referenciák persze sokszor túlságosan szakmainak és részletesnek tűnhetnek, de ne ijedjünk meg, később nagy hasznát fogjuk venni minden itt leírt információnak.

CSS, megjelenés

Manapság már minden modern böngészőhöz létezik beépített fejlesztést támogató eszköz – menüből általában Fejlesztői eszközök (Developer Tools) néven érhetjük el, vagy a Ctrl+Shift+I billentyűkombinációval – vagy letölthető kiegészítő (a Firefoxhoz a Firebug). Ez utóbbit az Eszközök, Kiegészítők menüpontokon keresztül telepíthetjük, és az F12 segítségével nyithatjuk meg – csukhatjuk be. Ezen keresztül mutatom be az egyes eseteket, mivel tapasztalataim szerint ez az egyik legjobban használható program.

HTML-ek gyártása közben sokszor előfordul, hogy egy elem nem úgy néz ki, ahogy azt elképzeltük. Talán az egyik legfontosabb, hogy megértsük, mi az a doboz modell, hogyan működik az elemek úsztatása, valamint az elemek pozícionálása, minden más adja magát.

A Firebugban az elemek kijelölése többféleképp történhet, például a bal felső sarokban található, kék négyzeten lévő egérkurzor ikonnal, segítségével elég rákattintani a képernyőn egy pontra, és a HTML fülön azonnal megtudunk választottunkról mindent. A bal oldalon látható a HTML fastruktúra, ha itt egy sor fölé visszük az egeret, a böngészőben az aktuális elemet különböző színekkel jelöli a program: a kék a tartalmat, a lila a kitöltést, a barna szín a keretet, míg a sárga a margót.

Jobb oldalon az aktuális stílusdefiníciók jelennek meg, a listában lefelé görgetve megtekinthetjük az összes, az elemre vonatkozó stílust. Ezt lehetőségünk van átszerkeszteni, vagy akár új tulajdonságokat hozzáadni, így élőben kipróbálhatjuk a változtatásokat, az oldal újratöltése nélkül.

JavaScript

A Firebugban a Konzol fülön tudjuk követni szkriptjeink hibáit: ha megtörtént a baj, piros betűkkel adja tudtunkra a program, merre kezdjünk el keresni. Ha ez a fül aktív, a Konzol felirat mellett megjelenik egy kis háromszög, itt tudjuk személyre szabni a kapott üzeneteket, valamint érdemes bekapcsolni a „Veremmel kiíratása a hibák mellett” (sic!) menüpontot, mert ekkor azt is láthatjuk, hogy a függvényeink milyen paramétereket kaptak.

Ha tudatosan szeretnénk megállítani a szkript futását egy bizonyos helyen, írjuk be a forrásba a következőt: debugger;. Ha ide érkezik a programunk, a Firebug átvált a Szkript fülre, ahol bal oldalon lenn a kódot, jobb oldalon pedig további hasznos információkat láthatunk: a Figyelés fülön az aktuális változók értékei jelennek meg, a Verem fülön pedig a függvényhívások paramétereikkel, az ide vezető úton.

Üzeneteket úgy is küldhetünk szkriptünkből, hogy nem szakítjuk meg a program futását, ehhez használjuk a console.log() parancsot. Roppant hasznos tulajdonsága, hogy a tömböket és objektumokat szépen, fastruktúrában jeleníti meg, így nagyon könnyen olvasható a tartalmuk. Figyelem! Az oldal élesítésekor ne felejtsük el kivenni a kódból ezeket a parancsokat, mert hibát okozhatnak ott, ahol nincs Firebug telepítve, ráadásul nem is a felhasználókra tartoznak ezek az üzenetek.

A DOM fülön tekinthetjük meg a dokumentumunk összes nyilvános változóját egy nagy fastruktúrában, ahol ezek az értékek egy része egyébként szerkeszthető is. Itt aztán tényleg belemászhatunk a böngészőnk lelkivilágába, és megtudhatjuk a legapróbb bitig, hogy elemeink milyen tulajdonságokkal rendelkeznek.

PHP

A legegyszerűbben a következő három parancs használatával kérhetünk állapotinformációt a programunk futásáról: print_r(), get_defined_vars() és debug_backtrace(). A print_r() egy segédfüggvény, formázottan jeleníti meg a paraméterként megkapott változókat; érdemes a kimenete köré rakni egy <pre> … </pre> taget, így tömbjeink és objektumaink tartalma jól olvasható lesz.

A get_defined_vars() egy tömbben adja vissza az adott helyen létező változók értékeit, míg a debug_backtrace() segítségével megjeleníthetjük a vermet, azaz azon függvények listáját, amelyeken keresztül eljutottunk az adott pontra, mellettük a bejövő paraméterekkel és a definiált változókkal. Egy komolyabb rendszernél ez az adattömb meglehetősen nagy lehet, de általában elég az utolsó pár elemét vizsgálni, hogy rájöjjünk a hiba okára. Itt is fontos megjegyezni, figyeljünk arra, hogy élesítéskor még véletlenül se jelenjenek meg ilyen hibaüzenetek, mert az átlagfelhasználó számára zavarók, a nem tisztességes látogatók számára pedig támpontot adhatnak; ilyen esetben megoldás lehet a hibák naplózása egy fájlba vagy adatbázisba.

A manapság népszerű AJAX-os alkalmazások hibakeresésére használhatjuk a Firefox Firebugra épülő FirePHP kiterjesztését, aminek használata nagyon hasonló a javascriptes console.log() függvényéhez. Az eredményt a Firebug Konzol fülén tekinthetjük meg, a PHP-s tömbjeink és objektumaink formázottan, olvashatóan jelennek meg.

Végszó

Jóbarátunk a kereső! Senki se érezze magát különlegesnek, az épp aktuális problémával nagyon nagy valószínűséggel már más is találkozott, s meg is osztotta a tapasztalatait. Mint mindenhol, ebben a szakmában is fontos, hogy lépésről lépésre haladjunk, azaz tanuljuk meg a szakmai nyelvet és az angolt, ismerjük az adott programozási vagy leírónyelv parancsait-lehetőségeit, hogy minél pontosabban tudjuk feltenni a kérdésünket.

Miután ötször végigolvastuk az adott nyelv dokumentációját, átnyálaztuk a függvényekhez tartozó kommenteket, átkutattuk az internet legutolsó, legporosabb szegletét, és még mindig nem találtuk meg a Választ, akkor érdemes a kollegák segítségét kérni fórumokon, például a Weblaboron. Ne felejtsük: ők is emberek, valószínűleg dolgoznak, és kevés az idejük, ezért adjuk meg nekik a tiszteletet!

Mit és hogyan írjunk le?

  • Mik a körülmények, hogyan lehet reprodukálni a hibát?
  • Ha van hibaüzenet, másoljuk be!
  • Melyik böngészőben teszteltük?
  • Szerveroldali nyelv esetén írjuk le a használt szoftverek verziószámait!
  • Használjuk a kódszínezőt!
 
1

Na, ha szerintem valami

saxus · 2012. Feb. 4. (Szo), 18.32
Na, ha szerintem valami igazán rossz út, az a print_r, echo és társai, mint debug eszköz. Aki örökölt már kikommentelt és/vagy kevésbé kikommentelt (=bennfelejtett) print_r/echo halmkokat kódban, az tudja miről beszélek.

Szvsz. inkább arra kellene rászoktatni - főleg a kezdő - fejlesztőket, hogy ne mindenféle "developer szerveresdi"-t játszanak (eleve eltérő a production és a dev környezet igényei, és akkor még csak a legegyszerűbb esetekről beszéltem, nincs semmi köztes testing vagy hasonló környezet!), és normális eszközökkel (pl. adott esetben xdebug).

Igaz, ezen a téren maga a nyelv sem könnyíti meg az ember dolgát, hiszen nincs annyira jó eszköz, mint pl. más nyelvekhez (ld. egy VS+.NET vagy egy Eclipse+Java), mert azért az xdebug is tud lassú lenni, arról nem is beszélve, hogy ilyen kényelmi funkciókat vajon mikor fog tudni, minthogy futás közbeni kódszerkesztés (ugye nem csak weben használjuk a PHP-t) vagy változó értékének módosítása (FIXME, de utoljára Eclipse-ből nem lehetett, mikor néztem).
2

Nekem a kivételek dobása és a

inf3rno · 2012. Feb. 4. (Szo), 19.23
Nekem a kivételek dobása és a loggolás bőven elég szokott lenni. Aztán ha még teszteket is ír az ember, akkor meg már végképp nincs szükség az echo-ra, és társaira...
3

Ezt hogy érted?

H.Z. v2 · 2012. Feb. 4. (Szo), 19.31
Szvsz. inkább arra kellene rászoktatni - főleg a kezdő - fejlesztőket, hogy ne mindenféle "developer szerveresdi"-t játszanak

Ugye nem arra gondolsz, hogy az éles szerveren kellene végezni a fejlesztéseket és teszteléseket?
4

De szerintem arra gondolt

MadBence · 2012. Feb. 4. (Szo), 19.37
Csak pont fordítva :)
8

Nem

saxus · 2012. Feb. 4. (Szo), 23.19
hogy ne mindenféle "developer szerveresdi"-t játszanak


Azt hittem, elég egyértelmű ;) Arra gondoltam, hogy egy kezdőnek tipikusan az az első, hogy keres valami tárhelyet (legyen az free, bérelt, VPS, saját szerver, akármi), ahol "tud fejleszteni" tipikusan FTP vagy SCP-n keresztül.
10

Na ez az...

H.Z. v2 · 2012. Feb. 5. (V), 12.07
Nálam a developer szerver az valami saját telepítésű, a fejlesztési igényekhez igazított szervert jelent.
Így a "ne mindenféle developer szerveresdi"-ből az jött le, hogy épp erről beszélnéd lefelé őket. :)
6

Kezdőknek

Pepita · 2012. Feb. 4. (Szo), 21.31
Ez a cikk a kezdőknek szól, nekik - elsőre - bőven jó az echo és társai. Ha olvasod a kérdéseiket, problémáikat, te is láthatod, hogy nagyon sok esetben ebből már rá is jöttek volna a hibájukra.

A "bennfelejtett" cuccokkal teljesen igazad van, de ki az aki egy kezdő kódját "megörökli" és nem újat ír helyette? Saját magának meg felejtse csak bent, ha nem tud rendet tartani. Ezeket a kiíratásokat ugye csak addig kell meghagyni, amíg a hiba megoldódik...

Szerk.: írd meg a folytatását a cikknek, hasznos lenne, és akkor pótolhatod is, amit innen hiányolsz. Nem?
7

Kezdő maradhat amatőr is.

saxus · 2012. Feb. 4. (Szo), 23.18
Az a gond, hogy az előző és a mostani munkahelyemen is megörököltem olyanok kódját, akik elvileg 10+ éve dolgoznak a szakmában. Hát... A mostani munkahelyemen külön szállóige a volt "kollégám" "nem vagyok amatőr!" beszólása az egyik leveléből.
5

Nagyon jó cikk!

Pepita · 2012. Feb. 4. (Szo), 21.29
Köszönöm mindannyiunk nevében!
A lényeg ott van, tömören, érthetően.
Azt kéne valahogy megoldani, hogy jól látható helyen maradjon később is.

Amiben lehetne jobb:
A fontosabb szavak/kifejezések jobbak lennének kiemelten, hogy később is könnyen megtalálhassák a keresett részt (egy normálisabb kezdő szerintem többször is bele fog nézni).
A végén a felsorolásban jó, hogy hangsúlyozod a kódszínezőt, de ahogy mostanában látom: a forráskód kérdéshez csatolását is külön hangsúlyozni kéne.

Összességében szerintem nagyon jó, kezdőnek nem kell elsőre több, mert sok lenne. (Persze lehetne további cikk(ek)ben tárgyalni azokat a megoldásokat, amiket a többiek itt hiányolnak/reklamálnak. Akár ők is megírhatnák ezeket!)
9

Köszönöm a javaslatokat,

Hidvégi Gábor · 2012. Feb. 5. (V), 09.49
Köszönöm a javaslatokat, egyetértek velük - a kiemeléseidet tényleg hasznosnak tartom, eszembe juthatott volna használni, a forráskódról írtam eredetileg, de az egyik átfogalmazás során úgy látszik valamiért töröltem a szövegből.
11

Jó a cikk, szükség van az

inf3rno · 2012. Feb. 5. (V), 12.48
Jó a cikk, szükség van az ilyen cikkekre, csak még mindig az a gond, hogy el fog tűnni a süllyesztőben :S
12

Nem kéne

joed · 2012. Feb. 5. (V), 21.59
Szerintem sem kellene az alapoktól kezdve rossz dolgokra rászoktatni a kezdőket. Van itt egy webinar:

PHP Development Best Practices


Ez pl. szerintem jó példa, hogy hogyan is kellene hozzákezdeni fejleszteni.

A var_dump-olásról. Ne legyen senki hipokrita, mindenki használta/használja debugolásra. A kezdőknek jó tudni, hogy persze ismerjék meg az említett print_r() féle függvényeket, de talán maguknak tesznek egy szívességet, ha helyből megismerkednek az xdebuggal is.
13

Szerintem sem kellene az

Hidvégi Gábor · 2012. Feb. 5. (V), 22.35
Szerintem sem kellene az alapoktól kezdve rossz dolgokra rászoktatni a kezdőket.
Hadd döntse el mindenki maga azt, hogy számára mi a jó és mi a rossz.
14

Szerintem

Bártházi András · 2012. Feb. 8. (Sze), 17.19
Nem mindegy, hogy valaki milyen gyakorlatot alakít ki, mert utána adott esetben nagyon nehéz tőle megszabadulni, továbblépni. SZVSZ joed felvetése igenis jogos volt. Vannak olyan (menő) cégek, ahol elfogadhatatlan a var_dump() használata, ha valaki ezt mondja egy állásinterjú során mint általa ismert megoldást a hibakeresésre, akkor szépen el lesz hajtva.
15

A felvetése jogos, de nekem

Hidvégi Gábor · 2012. Feb. 8. (Sze), 17.48
A felvetése jogos, de nekem agresszívnek tűnt, ahogy előadta.
16

Hadd döntse el mindenki maga

inf3rno · 2012. Feb. 8. (Sze), 19.00
Hadd döntse el mindenki maga azt, hogy számára mi az agresszív és mi nem. :D
Nekem nem tűnt agresszívnek, mondjuk nem nekem írta. Néha, ha le vagyok terhelve, akkor én is érzékenyebbé válok az ilyesmire... Nem hiszem, hogy joed személyeskedni akart volna, vagy bármi ilyesmit.

Szerintem maga a cikk egy jó bevezető ilyen téren, és várom a folytatást, amiben fejlettebb hibakeresési módokat is leírsz! Persze csak ha inkább javaslatnak, mint kényszernek érzed ezt a felszólítást. :-)
17

Valószínűleg velem is ez

Hidvégi Gábor · 2012. Feb. 8. (Sze), 22.08
Valószínűleg velem is ez volt, picit túlreagáltam.
Folytatást egyelőre nem igérek, mert frontend programozó lévén szerveroldali hibakeresésben nem vagyok annyira otthon, ezt rábízom másra.
18

Lépések

Pepita · 2012. Feb. 8. (Sze), 22.16
Igazad van abban, hogy aki valamire "rászokik", azt nehezen vetkőzi le. De talán leginkább a programozás közben ejtett hibákról kell leszokni, amikből ugye az elején rengeteg akad. Kár az első lépéseket "idegen" rendszerek tanulásával nehezíteni. Csak tényleg tovább kell lépni az első lépésektől. De azok legyenek későbbi lépések.