Ei koodi debuggaamalla kulu

Kirjoitin joskus aiemmin kielimuurista asiakkaan ja koodarin välillä blogissa Pardon my Jargon. Samassa raapustuksessa vilisi tietotekniikan termejä, jotka eivät käänny luontevasti suomeksi. Näistä yksi oli “debug”. Ilmainensanakirja.fi -sivusto ehdottaa termin suomennokseksi “etsiä ja poistaa virheet”, “hävittää hyönteiset”, “poistaa salakuuntelulaitteet” tai “testata”. Ammattikielessä puhumme “debuggauksesta”. Mutta mitä debuggaus sitten käytännössä on?

Debuggaus on koodin suorittamista, virheiden, eli “bugien”, etsintää ja poistamista. Jästien kielellä voidaan puhua myös “testaamisesta”. Ohjelmakoodia ajetaan pääsääntöisesti kehitys- ja testiympäristöissä ja tutkitaan, toimiiko se toivotulla tavalla. Tavallisesti tämä tapahtuu ohjelman kehitysvaiheessa ennen julkaisua tuotantoympäristöön. Käytäntö kuitenkin osoittaa, että bugeja päätyy aina myös tuotantoon. Tähän voi olla monia syitä, kuten esimerkiksi eroavaisuudet datassa, käytön volyymi, järjestelmien eroavaisuudet, tietoliikenneyhteydet, käyttäjien kyky tehdä asioita odottamattomalla tavalla, eri asemassa olevat planeetat ja niin edelleen. Tämän vuoksi olisi ideaalista, jos koodia voisi “testata” myös tuotantoympäristössä.

Bugin päätyminen tuotantoon ei siis välttämättä johdu kehittäjän laiskuudesta, syy voi olla nimenomaan ympäristöjen eroissa. Yleisimmin varmasti datassa, koska se ei yleensä ole samanlaista kuin testiympäristössä. Tuotannossa data on validimpaa, siitä pidetään ”parempaa huolta”. Sitä vastoin testissä dataa on yleensä vähemmän ja se on enemmän ”kuralla”. Varsinkaan kehitysympäristöihin ei voida portata dumppia suoraan tuotannosta. Tuotantodata sisältää salaisuuksia, joiden ulosvuotamisen riski halutaan ymmärrettävästi minimoida.

Järjestelmää on hyvin hankalaa tehdä täysin bugittomaksi, mutta ehkä olennaisempaa on se, miten sovellus käsittelee virhetilanteet. Tämä tarkoittaa sitä, että ohjelmaan on kirjoitettu asianmukainen virheenkäsittely niin ettei se kaadu ja/tai pamauta rumaa ilmoitusta käyttäjän silmille kun jokin bitti menee väärään kurkkuun. Ohjelman on otettava virhe kiinni ja ohjattava suoritus hallitusti eteenpäin esimerkiksi virhesivulle, missä kerrotaan mitä tapahtui ja että ei pidä olla huolissaan. Pahimmassa tapauksessa puutteellinen virheenkäsittely paljastaa järjestelmästä jotakin, mikä altistaa sen väärinkäytöksille tai hyökkäyksille.

Miten ongelmia sitten voi lähteä selvittämään? Riippuu ongelmasta ja siitä, kuinka hyvin sovellus on koodattu. Jos ohjelmaan on kirjoitettu hyvä virheenkäsittely, voi ratkaisu löytyä suoraan lokituksesta. Joskus on lähdettävä liikkeelle pelkän asiakkaan lähettämän kuvankaappauksen pohjalta ilman mitään muita parametreja. Tällöin kaiken avain on se, että ongelman saa jotenkin toistettua. Kun ongelma saadaan toistettua esimerkiksi kehitysympäristössä, on tämä jo osa ratkaisua. Jos koodiin pääsee vielä kiinni debuggerilla, on kuin laittaisi valot päälle hiilikellariin.

Joskus sitä joutuu toimimaan “sokeana” ja arvailemaan, mikä virheen voisi aiheuttaa. On vain kokeiltava jotain, mentävä intuitiolla. Tässä tapauksessa kaikki tulokset ovat toivottuja, jopa uusi erilainen virhe. Sehän tarkoittaa edistystä: ensimmäinen ongelma on taklattu ja niitä on edessä enää x-1 kappaletta. Yleensä kannattaa myös melko pian konsultoida kollegaa, pyytää apua boksin ulkopuolelta. Meillä T-Basella on loistava vertaistukiryhmä bugien selvittelyyn. Apua voi pyytää ja sitä myös saa hyvin matalalla kynnyksellä. Monemmat aivot tekevät paljommin järkeä.

Joskus kun johtolangat ovat vähissä, tehokas menetelmä voi olla systemaattisesti sulkea pois asioita, mitkä eivät ongelmaa aiheuta. Kun eliminoi mahdottoman, jäljelle jää totuus, oli se kuinka epätodennäköinen tahansa. Joskus tuntuu, että jokainen kivi ja käpy on käännettävä. Varmasti Edisonkin debuggasi sähkölamppuaan tovin verran ennen kuin oli kokeillut kaikki ratkaisut, jotka eivät ainakaan toimi. Kun lyö päätään seinään tarpeeksi kauan, niin seinäänkin tulee lopulta reikä.

Joskus ongelman selvittäminen kestää ja sen pariin on palattava myöhemmin. Hyvin nukutun yön jälkeen ongelma voi ratketa hetkessä. Tai keskellä yötä. Joskus ongelman syy on jo valmiiksi selvillä tai ilmeinen, mutta haasteena onkin löytää toimiva ratkaisu. Joskus debuggausta voidaan käyttää koodin paranteluun, kirjoittamaan siitä tehokkaampaa, luettavampaa, kauniimpaa. Debuggaus ei siis aina ole sitä, että tutkitaan, miksi jokin ei toimi. Se on ohjelman logiikan ymmärtämistä ja varmistamista, että sovellus toimii, kuten sen on suunniteltu toimivan. Debuggaaminen on yksi koodarin tärkeimmistä osaamisalueista. Aivan kuten kokki maistelee ruokaansa, on koodarin debugattava koodiaan.

Kirjoittaja Ossi Lommi yrittää poistaa koodistaan ainakin kaikki oravaa suuremmat ötökät.