logging vs debugging

Az utóbbi időben több olyan társasággal is találkoztam, akik folyton egy debugger előtt görnyedtek, emellett eléggé hanyagolták a debug szintű loggolást. Nekem nem volt szimpatikus ez a megközelítés. Láttam félrecsúszott helyzeteket is, amikor hatékonysági, többszálú vagy tranzakciós (vagy ezek kombinációi) problémákat akartak megoldani a srácok csupán az IDE-be beépített interaktív debugger segítségével. Persze nem igazán sikerült.

Arról az esetről nem is beszélve, amikor kiment a szoftver élesbe és logok híján telefonon kellett a felpaprikázott ügyféltől kérdezgetni, hogy mi volt pontosan a hibajelenség és mi volt pontosan a tevékenység, amit csináltak. Egy jó log-állomány fekete dobozként vagy önvédelmi eszközként funkcionált volna, mert pontosan fel lehetett volna deríteni a szoftver gyenge pontjait, vagy hogy nem rendeltetésszerűen használták.

Nekem azért sem szimpatikus az interaktív debugolás, mert program státuszának adott pillanatbeli vizsgálata elveszi a figyelmet a dinamikus működésről. Csak előre lehet lépkedni, de ki tudja visszakövetni, hogy mi volt ötven lépéssel ezelőtt és mi lehetett volna, ha egy bizonyos érték valahol máshogy van beállítva? Csak egy keskeny ösvényt járnak be ami egy adott prekoncepció alapján születik, holott inkább a kvantumszámítógép elv követése lenne a hasznos, ahol egy kódrész lefutásainak összes lehetséges variációját figyelembe vesszük. Ezt pedig leginkább sok tapasztalattal, tiszta fejjel és sok intuícióval lehet megcsinálni.

Kíváncsian hallgattam meg a Software Engineering Radio debugolással kapcsolatos részét, vajon mit mond egy olyan ember, akit már érdemes meginterjúvolni a témában.

Meglepődtem mikor ő is azt mondta, hogy rossz megoldás fejest ugrani rögtön az interaktív debugerbe. Előbb nem árt gondolkodni, minél jobban leszűkíteni a hiba lehetséges helyét, ha kell azzal hogy papírra leírjuk a tapasztalatokat. Esetleg hazamenni aludni.

Mesélt még róla, hogy ezek az IDE-be integrált debugerek nagyon kezdetleges eszközök. Viszont vannak olyan automatizált eszközök is amik amellett hogy futtatják a regressziós teszteket, hiba esetén vissza tudják keresni hogy az adott teszt mely verzióval működött jól utoljára és a verzió követő rendszerben milyen modulokban milyen változások történtek azóta. Ezáltal elég jól be tudják azonosítani a hibák lehetséges helyét és elkövetőjét. Érdekes dolgok ezek. Egyszer majd kipróbálom talán, addig is szorgalmasan reszelgetem a debug szintű logjaimat.

Gyertek JUM-ra 19.-én!

Update 2009.08.12: (Ezt azért írom, hogy ha már nem vagyok kinn a Szigeten, legalább valahogy mégiscsak elcsesszem az időt meló helyett.) A bejegyzés első része Enterprise Java alkalmazásokra vonatkozott, amelyek leginkább appszerverek belsejében futnak, de mostanában a Javascript felé sodort az élet, aholis kicsit már más a leányzó fekvése debugolás vs loggolás tekintetében.

Előszöris nem nagyon van hova loggolni. Leginkább alert popup-okat szoktak beszúrogatni ide-oda, amit aztán le kell okézni, vagy a HTML DOM bizonyos helyeire írogatnak be szövegeket. Trükkökkel lehet konzolt csiholni, de ez nem igazi log, tényleg csak egy konzol. De nem is ez a legnagyobb probléma, hanem hogy a java-val ellentétben a Javascript egy gyengén típusos dinamikus nyelv, tehát igen nehéz követni, hogy a program futásának adott pillanatában mi a környezet: milyen változók élnek, azoknak milyen mezői és függvényei vannak és ezek hogyan vannak egymásba ágyazva, egyáltalán mi a scope, mi a this referencia. Ráadásul elég sokat találkozik az ember külső Javascript komponensekkel, amiknek a működését nagy vonalakban nem árt megérteni. Viszont: A javascript-ben egy szálon fut a program, tehát nem eshetek komoly csapdákba debugolás közben a szinkronizációk és időzítések miatt.

Szóval ez az az eset, ahol mégiscsak bőszen használom az interaktív debuggert, nevezetesen a Firebug-ot, de Internet Explorer-re is van valami hasonló csak nem annyira ingyenes. Ennek ellenére Javascript klienseknél sem lenne haszontalan egy debug-log szintet kialakítani, amikor a böngésző Ajax-szal leküld bizonyos logokat a szervernek, de a tapasztalat azt mutatja, hogy olcsóbb szotyoláért egyetemistákat ráküldeni a gui-ra kattintgatni.