Bogárirtás IT módra – avagy mindent a debuggingról

1. rész

Miért debug?

A “debugging” kifejezést ma már átvitt értelemben használjuk, de az eredete nagyon is valós, fizikai problémára utalt. 

Maga a kifejezés Grace Hopper admirálishoz és csapatához kötődik. 

1947-ben ő is tagja volt annak a csapatnak, amely a Harvardon a Mark II számítógépen dolgozott. Amikor egy moly szorult a számítógép reléi közé, ezzel fennakadást okozva, a csapat egy egyszerű “bogártalanítással” (debugging) oldotta meg a problémát.

A moly, mai napig megtekinthető a Smithsonian Múzeumban.

Mi a hibakeresés?

Tegyük fel, hogy programozó vagy és van egy programozási feladat, amire készítesz egy megoldást. Ez egy vagy több szövegfájl, olyan, mint amit a Windows Jegyzettömbben is készíthetnél (ez a forráskód). Ezeket a fájlokat utána az adott nyelvre jellemző nyelvi környezet értelmezi

  • vagy átalakítja számítógép által érthető nyelvre (ez a fordítás – compiling, amit a fordító – compiler – végez), 
  • vagy közvetlenül értelmezi a beírt sorokat (értelmezés – interpret, amit az értelmező – interpreter – végez), 
  • vagy a kettő hibridjét alkalmazza, ahogyan a Java (egy fordító lefordítja egy “köztes” nyelvre, amit egy értelmező értelmez).

Az első probléma, amivel programírás közben szembesülhetsz az az, hogy az adott nyelvi környezet nem érti, hogy mit akartál kifejezni. Ugyanúgy, ahogy a beszélt nyelvekben az anyanyelvi beszélő nem érti azt, aki az idegennyelv-tanulás kezdetén van, mert nem jól rakta egymás mellé a szavakat, vagy súlyos nyelvtani hibát vét. Hasonló előfordulhat a programozásban is: a kezdő programozó annyira súlyos nyelvtani hibákat vét, hogy az a számítógép számára nem érthető. Ezek a szintaktikai hibák

A szintaktikai hibák kezelésében általában segít az a szoftver, amiben a programokat írjuk (IDE – integrated development environment – integrált fejlesztőkörnyezet). Az IDE jellemzően nagyon a programozó keze alá dolgozik, igyekszik minél jobban segíteni a munkáját, így például piros hullámos vonallal aláhúzza, ha nem ért valamit (tiszta általános iskola, nem igaz? 😀). 

A szintaktikai hibák előfordulása a tapasztalattal csökken – pontosan úgy, ahogyan az idegennyelvet tanuló is egyre rutinosabb, és egyre kevesebb hibát vét.

A programhibák másik része nem nyelvtani eredetű, hanem inkább a jelentése nem stimmel: a program sorai (“mondatai”) önmagukban helyesek, de nem azt a hatást érik el, azaz nem azt jelentik, mint amit a programozó ki akart fejezni. Mint amikor az ember elmesél egy viccet, amivel az a szándéka, hogy megnevettesse a közönségét, de valami balul sül el, és többen megbántódnak rajta: a mondatok helyesek voltak, de nem a megfelelő hatást érték el. A programozás esetében azok a hibák, amikor nyelvtanilag helyes programsorokat írunk le, de azok nem azt a feladatot oldják meg, amit szerettünk volna, azok a szemantikai hibák

A problémát a program jelentése hordozza. A szemantikai hibák a nehezebben megtalálható hibák, mert ha a programozó tudná, hogy az úgy nem lesz jó, akkor nem úgy írná meg, ahogyan a bántó viccet mesélő tréfamester sem sejti, hogy ebből sértődés lesz, míg a történet végére nem érünk.

A szemantikai hibák kiderülése esetén jöhet a nyomozás: van egy eredményünk, ami nem felel meg a várakozásainknak, és ki kell deríteni, hogy hol ment félre a gondolatmenet. Kicsit ahhoz hasonlít, mint amikor az ember jó krimit olvas: ott is van egy cselekménysorozat, aminek az eredménye ismert (valaki meghalt), és ki kell nyomozni a jelekből, hogy ki, hogy, mivel és miért tette. A programozásban pedig meg kell tudni, hogy hogyan vezetett a lépéssor hibás eredményre, és hogyan lehet azt kijavítani. Persze van néhány különbség is: a programozás esetében az elkövető és a nyomozó ugyanaz a személy. Legtöbb esetben nem kell Sherlock Holmesnak lenni a megoldáshoz és sokkal több eszköz áll a nyomozó-elkövető rendelkezésére, hogy rájöjjön a rejtélyre, mint Sherlocknak. 

De mik is ezek az eszközök?