Onko bugien korjaaminen pelkkä hidaste oikeille töille? Ammattilaisen tekemä koodi on aina virheetöntä? Jos vastasit kyllä, et ole mielipiteesi kanssa yksin. On hyvin yleistä, että ohjelmistokehityksessä bugeista ajatellaan kielteisesti ja niiden olemassaoloa paheksutaan.
Tässä blogissa kurkistamme kuitenkin rohkeasti bugien maailmaan. Bugit ovat negatiivisesta maineestaan huolimatta täysin normaali osa ohjelmistotalojen arkea. Kysyimme siis suoraan Hurjan koodareiden bugiajatuksia: mikä on bugi, milloin siitä on haittaa, entä voiko bugeista olla jopa hyötyä?
Lyhyesti sanottuna bugi on koodissa oleva virhe, joka estää ohjelmistoa toimimasta oikein. Hyvin yksinkertainen havainnollistus on esim. se, että käyttäjä odottaa ohjelmalta vastausta nollan ja ykkösen väliltä, mutta sovellus yllättää vastaamalla “seitsemän”. Tällaisessa virhetilanteessa kone kyllä työskentelee ohjeen mukaan, mutta antaa bugin vuoksi vastauksena ei-odotetun tuloksen.
Alla olevaan taulukkoon keräsimme joitakin tarkempia ja teknisempiä esimerkkejä erilaisten bugien tyypeistä ja vaikutuksista. Bugeja on vaikka minkälaisia!
| Bugityyppi | Esimerkki kehittäjän työstä | Käyttäjän näkökulma |
|---|---|---|
| SDK:n eli ohjelmistokehityspaketin bugi: kehittäjän käyttämät hallinnan toiminnallisuudet eivät toimi oikein. | Hankaloittaa kehittämistyötä, koska SDK:n lähdekoodiin ei aina pääse tekemään omia bugikorjauksia. | Ei näy loppukäyttäjälle. |
| Graafinen bugi: Visualisoinnit eivät toimi oikein. | 3D-sovelluksessa koodi arpoo kahden elementin välillä, mikä näkyy kuvioiden “taisteluna” tai vääränä kuviona. | Käyttöliittymän elementit ovat sekavia, mutta kaikki muu toimii. |
| Logiikkavirhe: Väärin ajateltu ohjelman toimintalogiikka. | Koodissa on silmukka, joka ehtolauseen vuoksi jää ikuiseen suoritukseen ja estää toiminnon etenemisen. | Jokin ominaisuus ei toimi lainkaan. |
| Yhteensopivuusongelma: Ohjelmisto ei toimi tietyillä laitteistoilla tai laitteilla. | Bugi esiintyy vain Android tai iOS x.x-versiossa. | Ohjelmisto ei toimi oikein tietyillä laitteilla. |
| Semanttinen virhe: Syntaksi on oikein, mutta jokin muu koodin osa estää toiminnon. | Koodissa käytetään muuttujaa, jolla ei ole laskennan edellyttämää arvoa. | Jokin ominaisuus ei toimi oikein. |
| Tyyppivirhe: Muuttujan tietotyyppi on valittu virheellisesti tai väärin. | Muuttujaan asetettu arvo ei vastaa sille alustettua tietotyyppiä, joten metodi ei voi käsitellä muuttujaa. | Jokin ominaisuus ei toimi lainkaan. |
| Käyttöliittymäbugi: käyttöliittymän toiminnallisuudet eivät toimi odotetusti. | Näkyy muiden bugityyppien avulla: logiikkavirhe, graafinen bugi, responsiivisuuden ongelma tms. | Jokin toiminnallisuus on hämmentävä: esim. napin painalluksesta tapahtuu väärä asia tai näkymä ei asetu oikein. |
Tuotantoon karannut, ohjelmiston laatua heikentävä bugi on aina haitallinen ja ei-toivottu. Se voi aiheuttaa kielteisen käyttökokemuksen, haitata ohjelmiston toiminnallisuuksien käyttöä ja pahimmillaan luoda ohjelmistoon jopa vakavan, tietoturvaa uhkaavan haavoittuvuuden.
Lievien virheiden esiintyminen on silti normaalia etenkin uuden digitaalisen palvelun käyttöönoton aikana. Tällaisia vähemmän haitallisia bugeja voivat olla vaikkapa tyylittelyyn tai ulkoasuun vaikuttavat virheet, tai eri päätelaitteilla ilmaantuvat käyttöliittymien kankeat näkymät.
Esimerkiksi Android -laitteita oli viime vuonna jo yli 24 000 erilaista (lähde: Quartz). Jokaisen laitteen ja käyttöjärjestelmän välisen yhdistelmän yksityiskohtia lienee mahdotonta huomioida täydellisesti. Vaikka laitteet noudattavat tiettyjä standardeja, on niissä aina isompia tai pienempiä eroavaisuuksia. Tällaiset variaatiot voivat vaikuttaa mm. graafisiin elementteihin, kuten vaikkapa 3D-renderöintiin.
On kuitenkin olemassa myös yksi poikkeus sääntöön. Tuotannossa oleva bugi voi saada käyttäjiltä positiivisen vastaanoton, jos virhe ei ole kovin vakava ja se tarjoaa jotain viihdearvoa. Esim. digitaalisten pelien pelaajat saattavat innostua tutun pelin bugista, jos se mahdollistaa poikkeavan, inspiroivan ja ehkä hieman kummallisen pelikokemuksen.
Bugit voidaan mieltää keskeneräisenä kehittämistyönä. Siksi Hurjan sovelluskehittäjien arkeen kuuluu tunnistaa koodin virhelähteet ja ongelmakohdat. Kun bugien olosuhteisiin reagoidaan viipymättä, haittavaikutukset eivät pääse kasvamaan liian suuriksi. Näin myös korjaustoimenpiteet ovat nopeampia ja työaikaa säästyy toimivien ratkaisujen koodaamiseen.
Monet bugit ovat seurausta inhimillisistä mokista, kiireestä, ristiriitaisista konekäskyistä tai haasteista, joita ihan jokaisen erityistilanteen huomiointi ja kokonaisuuden yhdistäminen tuovat joskus tullessaan. Testaamisen merkitystä ohjelmistoprojektissa ja ohjelmiston laadun turvaamisessa ei siksi tulisi koskaan aliarvioida.
Testauksen laajuudesta ja menetelmistä sovitaan kuitenkin aina asiakkaan kanssa erikseen. Mitä huolellisemmin ja systemaattisemmin testaus tehdään, sitä suuremman osan se haukkaa projektin kokonaistyömäärästä. Esim. ei-kriittisiin järjestelmiin voi riittää usein kevyempi testausmenetelmä, kun taas kriittisissä järjestelmissä systemaattinen testaus on paikallaan.
Sopivan kattavat testausprotokollat ja -järjestelmät auttavat kehittäjiä löytämään monenkirjavat bugit ja rajoittavat tehokkaasti virheiden pääsyä tuotantoon. Sovelluskehittäjillämme on käytössään erilaisia automatisoituun ja manuaaliseen testaamiseen soveltuvia työkaluja. Mm. virheraportteja tarjoavat sovellukset ja ohjelmointiympäristöön liitetyt konsolit tarjoavat jopa reaaliaikaista virheseurantaa.
Laajemmissa projekteissa taas voi olla aiheellista tehdä koko ohjelmistoprojekti testivetoisesti. Testivetoinen kehitys on ketteriin menetelmiin kuuluva työskentelytapa, jossa koodit kirjoitetaan ja iteroidaan toimiviksi testien kautta. Kustakin löydetystä ja korjatusta bugista tehdään omat testitapaukset, ja jos sama bugi ilmenee uudestaan, virhe saadaan kiinni jo ennen julkaisua.
Testaus on tärkeää myös ylläpidon aikana. Esimerkiksi jos toteutuksessa hyödynnetään useiden eri toimittajien koodaamia osuuksia, saattaa bugi ilmaantua erillisen komponentin tai moduulin sisälle. Lopputuotteessa näkyvä bugi voi siksi olla heijastus päivityksistä ja muutoksista, joiden vaikutusalueen ennustaminen on kehittämisvaiheessa ollut mahdotonta.
“Etsin sovelluksessa näkyvien virheellisten tietojen lähdettä itsekseni, enkä yrityksestä huolimatta onnistunut paikallistamaan bugia. Kun kuvailin kollegalle sovelluksen toimintaa, ymmärsin samalla mikä koodissani on pielessä. Olin etsinyt logiikkavirhettä aivan väärästä kohtaa.”
– Jukka, sovelluskehittäjä.
Teknisten työvälineiden lisäksi bugit voidaan paikallistaa tiimin hyvän vuorovaikutuksen ja yhteistyön avulla. Katselmoinnit, oman koodin toimintalogiikan selittäminen kollegalle ja vinkkien kysyminen toisilta kehittäjiltä ovat varsin oleellisia bugien löytämisen ja ennaltaehkäisyn keinoja, koska monet mahdolliset ongelmakohdat ratkeavat jo ennen niiden muuttumista bugeiksi. Myös ei-toivotut, mutta korjatut bugit voivat olla ilmaantuessaan opettavaisia ja auttaa saavuttamaan entistä paremman lopputuotteen. Virheistä voi, ja pitää oppia.
Vaikka tuotantoon viety koodi ei saisi aiheuttaa käyttäjälle harmaita hiuksia, joskus bugi jää harmillisesti kiinni vasta tarkkaavaisen loppukäyttäjän ansiosta. Bugista ei tulisi koskaan moittia ohjelmiston käyttäjää. Mahdollisuus antaa ohjelmistosta palautetta ja saadun palautteen asianmukainen käsittely ovat nekin tärkeä osa bugien haittavaikutusten rajaamista.
Bugeihin törmää kaikkialla, niin isoissa kuin pienissäkin ohjelmistoissa, verkkosivustoilla ja muissa digipalveluissa. Bugeja on kaikenkokoisia ja -muotoisia, ja niiden sijainti, sekä haittavaikutusten tyyli ja laajuus vaihtelevat.
Bugeista ei kannata pyrkiä kerralla kokonaan eroon. Kyse on enemmänkin siitä, miten ja milloin virheisiin reagoidaan, ja kuinka ongelmalliset koodit korjataan osana normaalia ohjelmistokehitystä. Huolellisten bugitarkistusten tulee aina olla kiinteä osa kehittämistä ja ylläpitoa, jotta etenkin kriittiset bugit voidaan rajata pois ennen kuin ohjelmisto annetaan loppukäyttäjän ihasteltavaksi.
Bugiaihe on todella laaja, joten yksi blogiteksti on vain pintaraapaisu ison asian äärellä. Mutta olipa bugin olomuoto tai sijainti mikä tahansa, asiantuntevassa ohjelmistotalossa bugit eivät aiheuta paniikkia. Virheet tunnistetaan ja niitä ennaltaehkäistään osana normaalia arkea. Näin potentiaaliset bugit löydetään ja niiden haittavaikutukset pysäytetään jo alkumetreillä.
