Huolellisuutta ja selkeyttä tarvitaan jokaisessa työssä ja työtehtävässä. Se miten nämä ilmenevät, riippuu taas työstä. Koodauksessa ja koodarin työssä ylipäänsä nämä ilmenevät eri lailla kuin vaikka tutkijan kirjoittaessa artikkelia.
Missä kaikessa näitä tarvitaan?
Kaikilta vaaditaan huolellisuutta missä tahansa työssä, mutta koodarin tehdessä esimerkiksi pienen kirjoitusvirheen kehitystyössä, koko sovellus saattaa lakata toimimasta. Lievemmissä tapauksissa lopputulos saattaa olla eri kuin haluttu, mutta silti sovellus toimii. Kirjoittaessa artikkelia yksi kirjoitusvirhe ei vaikuta artikkelin luettavuuteen eikä siitä aiheudu sen kummempia ongelmia.
Näitä ei tarvita vain kirjoittaessa koodia tai dokumentaatiota, vaan myös lukiessa ohjeita ja muuta materiaalia. Aika, jonka säästää lukiessa ajatuksella ja huolellisesti verrattuna siihen, että palaisi viiden minuutin välein selaamaan ja etsimään oikeaa kohtaa, on merkittävä. Tämän lisäksi, huolellisesti luetun muistaa varmasti paremmin, kuin jos olisi vain silmäillyt tekstin läpi.
Koodatessa ja dokumentoidessa
Kehittäessä sovellusta huolellisuudesta ja selkeydestä on hyötyä sekä itselle, että myös muille mahdollisille sovelluksen kehittäjille ja lähdekoodin hyödyntäjille. Tähän sisältyy kaikkea koodaamistavoista dokumentaation selkeyteen. Kirjassa nimeltä ”The Clean Coder: A Code of Conduct for Professional Programmers” käydään läpi enemmän sovelluskehittäjän ammattitaitoon liittyviä asioita, mutta myös sivutaan huolellisuuteen ja selkeyteen liittyviä asioita.
Dokumentaatiota kirjoittaessa on hyvä olla huolellinen, ja pyrkiä selkeään tekstiin. Näin säästät sekä omaa aikaasi, että myös mahdollisen ulkopuolisen lukijan. Lisäkysymyksiä liittyen dokumentaation voi tulla aina, mutta mikäli kysymykset liittyvät asioihin, joiden olisi pitänyt tulla ilmi jo dokumentaatiosta menee tähän ylimääräistä aikaa sekä kehittäjältä että kysyjältä. Dokumentaation laajuus on tapauskohtaista, mutta lähtökohtaisesti mitä laajemmin asiat on käyty läpi, sen parempi.
Koodatessa esimerkiksi muuttujien nimeämisellä ja funktioiden selkeydellä saadaan sekä parempi kuva sovelluksen toiminnasta että näiden avulla myöhemmin samaan asiaan palatessa on helpompi jatkaa, kun ei tarvitse miettiä ja tutkia mitä mikäkin tarkoittaa. Sen sijaan että nimeää aloitusajan muuttujan st kannattaa se nimetä startTime. Sen lisäksi että nämä ovat selkeämmät ymmärtää, ne myös toimivat samalla omana dokumentaationaan.
Konkreettinen esimerkki selkeydestä
Yhtenä esimerkkinä huolellisuudesta ja selkeydestä – sekä lukijan että kirjoittajan osalta – voidaan tuoda esille tapaus, jossa opiskelijan opinnäytetyössä kehittämää sovellusta pystytettiin uudelleen testi- ja esittelykäyttöön. Ohjeistuksessa itsessään oli muutamia epäselviä kohtia, jotka kuitenkin hetken pohdinnalla saatiin ratkottua. Vaaditut lisäpaketit ja sovellukset, kansiorakenteet ja asetukset saatiin määritettyä, siltikään sovellus ei toiminut kuten pitäisi. Ohjeet käytiin uudelleen läpi sekä opinnäytetyön sovellukseen liittyvä osio luettiin huolella läpi, eikä näistä löytynyt mitään puuttuvia kohtia.
Tämän jälkeen alettiin tarkemmin tutkimaan lokitiedostoihin tallentuvia virheilmoituksia. Näistä ilmeni, että sovellus ei saanut yhteyttä asennettuun tietokantaan. Yhteysasetuksista tarkistettiin, että kaikki asetukset täsmäävät keskenään sovelluksen ja tietokannan välillä. Näistä katsoessa ei nähty eroavaisuuksia. Koska annetuissa ohjeissa ja dokumentaatiossa ei ollut tietokannan osalta muuta mainintaa kuin että voidaan käyttää paikallista tai ulkoista tietokantaa. Perusasetukset eli esimerkiksi käyttäjä ja salasana oltiin luonnollisesti asetettu kuten aina tietokantojen kanssa ilman eri ohjeistusta.
Käytettävän tietokannan oletusasetuksia, tässä tapauksessa käytettävän portin numeroa, ei nähty tarpeelliseksi tarkistaa muuten kuin nopeasti katsomalla, että samat portit ovat käytössä. Hetken ihmettelyn jälkeen sovelluksen käyttämä portti katsottiin uudelleen ja huomattiin että viimeinen numero olikin eri. Tähän ei olisi mennyt aikaa, mikäli dokumentaatiossa tai ohjeissa olisi ollut maininta, että syystä tai toisesta, käytettävää porttia on muutettu oletusasetuksen kohdalla.
Mitä tästä opimme?
Edellisen esimerkin perusteella nähdään, että huolellisuus ja selkeys kannattaa aina, oli kyse sitten lukijasta tai kirjoittajasta, koodista tai ohjeista. Kaikki pienimmätkin yksityiskohdat kannattaa katsoa läpi, ja erityisesti jos ne kirjoittajastakin tuntuvat sekavalta, kannattaa ne avata mahdollisimman yksityiskohtaisesti. Omalla tavallaan huolellisuus ja selkeys myös kehittää laatua, koska kaikkiin pienimpiinkin yksityiskohtiin tulee kiinnitettyä enemmän huomiota.
Juuso Saarinen on toiminut sovelluskehittäjän tehtävissä HAMK Smart -tutkimusyksikössä neljä vuotta. Digitaaliset ratkaisut ja alustat -tutkimusryhmässä hän on päässyt tuottamaan monipuolisesti erilaisia sovelluksia mm. AvoinHäme- ja DigiCoach -hankkeille. Saarinen on valmistunut tietojenkäsittelyn tradenomiksi HAMKista vuonna 2016.
