Dokumentaation puute: ohjelmistokehityksen Akilleen kantapää

Yritys saa ohjelmistotilauksen. Toiminnallisista vaatimuksista keskusteltaessa huomataan, että moni ohjelmiston tarvitsema komponentti on jo toteutettu aiemmissa projekteissa, ja niitä voidaan hyödyntää. Luvataan siis lyhyt toimitusaika – tuotehan on jo käytännössä valmis. Kun aiemmin tehtyjä osasia aletaan käydä lävitse, huomataan, ettei yhdellekään ole kirjoitettu käyttöohjetta eikä dokumentaatiota, koodia ei ole kommentoitu juuri lainkaan ja tekijät ovat vaihtaneet firmaa jo hyvän aikaa sitten. Pahimmassa tapauksessa jotkut komponentit on vielä kirjoitettu kielellä, jota juuri kukaan tämänhetkisistä työntekijöistä ei osaa. Suurin osa projektista kuluu vanhan koodin läpikäymiseen ja testaamiseen, bugien etsimiseen ja joidenkin osuuksien uudelleenkirjoittamiseen. Varsinaiset uudet ominaisuudet laaditaan hirveässä kiireessä, osa parametreista kovakoodataan ja väliaikaiseksi tarkoitettuja ns. purukumipaikkauksia lätkitään sinne tänne. On sanomattakin selvää, että kommentointi jää taas tekemättä. Hirvittävän ylityörupeaman jälkeen ohjelmisto saadaan toimitettua asiakkaalle ajallaan, ja kaikki työntekijät pitävät sormiaan ristissä, etteivät joutuisi vastaamaan ylläpidosta tai saisi yhtäkään tukipyyntöä.

Kuvattu tilanne on valitettavan yleinen ohjelmistoalalla. Jokainen alan perusteos painottaa dokumentaation tärkeyttä, mutta silti se liian usein jää tekemättä. Yleinen syy on kiire. Kun jokin ominaisuus pitää saada toimimaan mahdollisimman nopeasti, tuntuu, ettei samanaikainen koodin kommentointi vie asiaa eteenpäin. Kun ominaisuus on sitten saatu valmiiksi, rynnätään suin päin toteuttamaan seuraavaa ja jätetään dokumentaatio myöhempien aikojen murheeksi. Kommentointia ei kuitenkaan pidä ajatella kehitystä hidastavana tekijänä. Ohjelmistoprojekti on aina yhteistyötä, ja kommentit auttavat muita kehitystiimin jäseniä ymmärtämään, miksi kyseinen toteutustapa on valittu. Kehityksen aikainen kommentointi helpottaa myös tekijää itseään jäsentelemään ajatuksiaan. Luultavasti seuraavalla viikolla tekijä itsekin saattaa olla unohtanut kehityksen aikaisen ajatuksenjuoksunsa. Hyvin usein avokonttoreissa voi kuulla lauseen: ”Mitähän olen tuossakin ajatellut?”

Toinen yleinen syy on veteen piirretty viiva työvaiheessa olevan ja valmiin ominaisuuden välillä. Kehittäjä saattaa ajatella, ettei viitsi kommentoida koodiaan niin kauan kuin se on työvaiheessa, sillä kaikkihan voi vielä muuttua. Testivaiheessa oleva koodinpätkä voi kuitenkin muuttua lopulliseksi versioksi yllättävän nopeasti sen saavutettua riittävä toiminnallisuus eikä kehittäjä välttämättä rekisteröi tätä, vaan siirtyy vain vaiheittain kehittämään seuraavaa ominaisuutta. Näin aiempi koodinpätkä sekä sen kommentointi unohtuvat ajankohtaisempien ongelmien täyttäessä mielen.

Projektipäälliköiden tulee myös muistaa, että dokumentointi on olennainen osa ohjelmistokehitystä, ja budjetoida myös sille aikaa. Parasta olisi varmistaa tämä viikoittain erillisten osasten valmistuessa. Viimeistään projektin loputtua tulee varmistaa, että koodi on riittävän hyvin kommentoitu ja erillinen dokumentaatio käyttöohjeineen on laadittu. Tämä helpottaa ylläpitoa ja muuttaa hiljaisen tiedon näkyväksi. Pitää aina muistaa, että kone suorittaa koodia, mutta sitä laatii ja lukee (ainakin toistaiseksi) ihminen.

Juha Hirvonen, SeAMK Tekniikka