Ohjelmistoarkeologia ratkoo vanhojen ohjelmistojen kirouksia

Kirjoittanut Aki Haapamäki
Julkaistu

Yrityksillä on usein haasteena omat vanhat ohjelmistot ja järjestelmät, joihin ei enää saada uusia ominaisuuksia tai joiden toiminta tai käytettävyys ei vastaa tämän päivän odotuksia. Kun ohjelmisto on ylittänyt parhaat päivänsä ja sen alkuperäinen kehitystiimi ei ole enää tavoitettavissa, voi olla, ettei halukkaita jatkokehittäjiä löydy. 

Tämä voi johtua siitä, että koodia ei ymmärretä tai siihen ei vain yksinkertaisesti enää haluta kajota. Ohjelmistosta on tullut varsinainen muumion kirous, jolle manataan yrityksen eri osastoilla ja pahimmillaan asiakkaita myöden. 

Vaikka tilanne voi näyttäytyä toivottomana, niin ohjelmistoarkeologia on keino selvittää ohjelmiston nykytila ja mahdollistaa jatkokehitys. Tällöin ei tarvitse tehdä täysin uutta järjestelmää tai kärsiä huonosti toimivista ratkaisuista. 

Ohjelmistoarkeologia kaivautuu ohjelman toimintaan

Suomen museoliiton mukaan arkeologia on tiede, joka tutkii menneisyyttä maassa ja vedessä säilyneiden jäännösten avulla. Sen tutkimuskohteina ovat ihmisten elämisestä ja työskentelystä syntyneet esineet ja rakenteet tai muodostelmat. 

Ohjelmistokehityksessä tämä sama määritelmä voisi kääntyä muotoon: ohjelmistoarkeologia on toimintaa, joka tutkii olemassa olevan ohjelmiston rakennetta, toiminnallisuutta ja menneisyyttä. Tutkimuskohteina ovat lähdekoodit, versionhallinta, tiketöintijärjestelmän merkinnät ja muu mahdollinen dokumentaatio, jotka ovat syntyneet ohjelmiston kehittäjien toimesta.

Kun perinteinen haltuunotto ei riitä

Mitä eroa on perinteisellä ohjelmistokehitysprojektin haltuunotolla ja ohjelmistoarkeologialla? Periaatteessa ei mitään, mutta jälkimmäisen valintaan ohjaa suurempi epävarmuus siitä, miksi ohjelma toimii tietyllä tavalla tai miksi tiettyjä ratkaisuja on tehty itse ohjelmakoodissa.  

Ihanteellisessa tilanteessa ohjelmistokehitysprojektin haltuunotto alkaa keskustelulla ohjelmiston suunnittelijoiden, kehittäjien ja käyttäjien kanssa. Keskustelua on tärkeä pitää yllä koko prosessin ajan, jotta saadaan kerättyä myös hiljaista tietoa, jota ei ole dokumentoitu.

Haltuunotossa tutustutaan ohjelmiston olemassa olevaan dokumentaatioon, kehitysympäristön pystytykseen ja julkaisu- ja testausprosessiin. Varsinaiseen koodiin perehtymistä unohtamatta. Lisäksi käydään läpi tiketöintijärjestelmän sisältö ja versiohistoria. 

Mikäli kokonaisuus on selkeä ja tiketöintijärjestelmässä on tehtävät priorisoitu, voidaan aloittaa ohjelmiston jatkokehitys.

Arkeologisen ohjelmistoprojektin tunnusmerkit

Mikäli projektin haltuunotto ei onnistu edellä kuvatulla tavalla, voidaan olla arkeologisen työn äärellä. Tällöin tietoa joudutaan selvittämään laajemmin, ennen kuin kehitys kannattaa aloittaa.

Tyypillisiä puutteita, joihin ohjelmistoarkeologiassa törmätään, on ohjelmiston suppea tai täysin puutteellinen dokumentaatio. Useimmiten tämä tarkoittaa, että alkuperäisiä ohjelmiston toimintaa kuvaavia vaatimuksia ei ole dokumentoitu kunnolla. Ohjelmistolla ei myöskään ole testejä, jotka määrittävät, miten ohjelmiston tulisi toimia.

Ei ole poikkeuksellista, ettei lähdekoodilla ole versionhallinnan historiaa, tai mikäli sellainen on, yksittäiset muutokset (commit) ovat liian laajoja ja niitä ei ole kommentoitu järkevästi. Muutokset voivat olla myös linkittämättä tiketöintijärjestelmään, joka antaisi tarkempaa tietoa alkuperäisestä muutostarpeista tai -vaatimuksista. 

Lisäksi haasteita voi olla tiketöintijärjestelmässä itsessään, jonka tiketit ovat huonosti dokumentoitu tai järjestelmää ei ole lainkaan. Ohjelmisto saattaa olla joissain tapauksissa niin vanha, että alkuperäisiä kehittäjiä tai suunnittelijoita ei ole tavoitettavissa. Ei ole poikkeuksellista, että ainoa dokumentaatio on ainoastaan itse lähdekoodi.

Usein ohjelmistoarkeologisissa tapauksissa törmätään projekteihin, joissa ohjelmisto on tehty kerralla valmiiksi, eikä sitä ole aktiivisesti ylläpidetty vuosien saatossa. Välttämättä kukaan ei osaa kertoa, miten asiat toimivat, vaikka alkuperäisiä kehittäjiä olisikin tavoitettavissa. Tähän voi liittyä myös heikosti dokumentoitu tai kommentoitu lähdekoodi tai ettei sitä ole rakennettu itsestään dokumentoivalla tyylillä. Voi olla myös, että ohjelmistoarkkitehtuuri, koodin rakenne tai sisäinen laatu ovat huonoja. 

Ohjelmistoarkeologin työkalulaatikko on laaja

Mikäli ohjelmistossa on aiemmin mainittuja puutteita, sen ylläpitäminen tai jatkokehittäminen voi olla vähintäänkin hankalaa. Tällöin ohjelmistoarkeologian avulla lähdetään selvittämään ohjelmiston toimintaa ja sisäistä rakennetta.

Ensisijaisesti pureudutaan siihen, miten ohjelma toimii tällä hetkellä. Lisäksi pyritään selvittämään syitä, miksi se toimii, siten kuin se toimii tällä hetkellä. Ohjelman toimintaa kooditasolla selvittämällä nähdään sen rakenne ja miten eri komponentit kommunikoivat keskenään

Usein vanhoissa ohjelmistoissa koodi on kirjoitettu isoihin ja monimutkaisiin kokonaisuuksiin ja sen ymmärtäminen suoraan on hyvin vaivalloista. Jotta koodia voidaan ymmärtää paremmin, käytetään erilaisia työkaluja ja sitä pilkotaan pienemmiksi kokonaisuuksiksi. Työ saattaa kestää pitkäänkin, sillä aina ei tiedetä, miksi ohjelmistoon on tehty tietynlaisia ratkaisuja. 

Jotta tutkimuksissa ja koodin uudelleen jäsentelyssä ei hajotettaisi toimivia ominaisuuksia, täytyy sovellukselle rakentaa automaattinen testausjärjestelmä. Se toistaa ennalta määritettyjä testejä automaattisesti, jolloin riski sille, että ohjelman toiminta rikkoutuu pienenee merkittävästi. Automaattinen testaus on siis kuin arkeologisten kaivausten tukirakenne, joka mahdollistaa etenemisen turvallisesti, ilman että koko rakennelma romahtaa. 

Debuggerin käyttö ja trace-lokitusten lisääminen järjestelmään ovat myös tärkeässä osassa, kun selvitetään ohjelmiston toimintaa ja rakennetta. Monimutkaista järjestelmää on hankala alkaa tulkitsemaan ilman näitä aputyökaluja. 

Kun automaattisen testauksen avulla nähdään, ettei ohjelma lähde toimimaan eri tavoin, voidaan koodia jäsentää järkevämpiin kokonaisuuksiin ja refaktoroida eli uudelleenkirjoittaa. Refaktoroinnilla parannetaan muun muassa lähdekoodin luettavuutta ja selkeytetään ohjelmakomponenttien työnjakoa. 

Monesti ohjelmiston rakennetta selvitettäessä kehittäjälle tulee mieleen kysymys, miksi asiat on tehty näin? Suunnitteluratkaisuja ja syitä niiden takana on hankala lähteä selvittämään ainoastaan koodista. Siksi ohjelman ratkaisut aukeavat usein keskustelemalla palvelun aiempien kehittäjien ja käyttäjien kanssa. Voi olla, että osa kysymyksistä voi ohjelman käyttäjälle olla täysin selkeitä hänen alaansa liittyviä käytäntöjä. Vastausten löytäminen myös näihin, auttaa monesti ymmärtämään ohjelmiston ratkaisuja. 

Arkeologia mahdollistaa olemassa olevan ohjelmiston tulevaisuuden

Ohjelmistoarkeologia on työvaihe, jonka avulla varmistetaan ohjelmiston tarkoituksenmukaiset jatkokehitysmahdollisuudet. Kun sen avulla on saatu hyvä kokonaiskuva ohjelmiston kehityshistoriasta sekä nykytilasta, on helpompaa määrittää jatkokehityksen laajuus ja vältetään turhat – ja usein kustannustehottomat – sudenkuopat hankkeen matkalta. 

Laajoissa järjestelmissä ohjelmistoarkeologia voi edetä osajärjestelmästä toiseen ja sykli voi tarvittaessa toistua joissain järjestelmän osioissa. Tällöin kokonaisuuden toiminta voidaan varmistaa koko prosessin aikana. 

Ohjelmistoarkeologia voi kuulostaa laajamittaiselta projektilta. Ja sitä se saattaa ollakin, mutta sen hyödyt ovat tuntuvia. Se mahdollistaa olemassa olevan ohjelmiston tuomisen teknisesti tähän päivään, jolloin sen jatkokehitys on mahdollista. 

Uuden järjestelmän rakentamiseen nähden hyötyjä ovat muun muassa se, että käyttäjät voivat jatkaa ohjelmiston käyttöä tuttuun tapaan ilman käyttökatkoja. Dataa ei tarvitse todennäköisesti siirtää järjestelmästä toiseen ja samalla vältytään laajamittaisilta käyttöönotoilta ja -koulutuksilta, jotka ovat usein uusiin ohjelmistoihin liittyviä salakavalia kuluja. Arkeologia mahdollistaa vanhan järjestelmän teknisen velan kiinniottamisen ja jatkokehittämisen tavalla, joka on näyttäytyy käyttäjille ohjelmiston orgaanisena kehittymisenä.