Vanha ohjelmisto: modernisoida vai uusia?

Tilanne on tuttu: sovellus, jolla yritys tekee töitä joka päivä, on kirjoitettu kymmenen tai useampi vuotta sitten. Se toimii, mutta kukaan ei uskalla koskea siihen. Alkuperäinen kehittäjä on lähtenyt aikoja sitten, sovelluskehyksen versio ei saa enää tukea, palvelin kaipaa päivitystä, jota sovellus ei kestä, ja jokainen pieni muutos vie viikkoja.

Silloin pöydälle nousee kysymys: korjataanko vanha vai heitetäänkö se pois ja rakennetaan uusi?

Olen viime vuosina palauttanut käyttökuntoon useita yli kymmenen vuotta vanhoja sovelluksia sekä julkisella että yksityisellä sektorilla. Yhdessäkään niistä vastaus ei ollut "heitä pois". Se ei tarkoita, että uusi rakentaminen olisi aina väärin — joskus se on oikeasti halvempaa. Alla ovat kriteerit, joiden perusteella teen tämän päätöksen.

Miksi "kirjoitetaan kaikki uudelleen" houkuttelee

Vanhan koodin lukeminen on raskasta, uuden kirjoittaminen hauskaa. Uusi projekti lupaa puhtaan pöydän: modernin tekniikan, siistin rakenteen ja kaiken sen, mikä vanhassa on pielessä.

Ongelma on siinä, että vanha sovellus ei ole pelkkää koodia. Se on kymmenen vuoden liiketoimintasäännöt. Jokainen outo if-lause, jota kukaan ei enää ymmärrä, on todennäköisesti lisätty syystä: erikoistapaus yhdelle asiakkaalle, lakimuutos, kirjanpitäjän pyyntö, virhe, joka ilmeni eräänä vuodenvaihteena. Näitä sääntöjä ei ole kirjattu mihinkään. Ne ovat vain koodissa.

Kun sovellus rakennetaan alusta, kaikki nämä säännöt pitää löytää uudelleen — yleensä vasta, kun uusi järjestelmä on otettu käyttöön ja jokin menee vikaan.

Miksi iso uudelleenkirjoitus epäonnistuu niin usein

Isossa uudelleenkirjoituksessa toistuvat lähes projektista toiseen samat ansat:

• Liikkuva maali. Vanha järjestelmä ei pysähdy uuden rakentamisen ajaksi. Liiketoiminta tarvitsee muutoksia edelleen, ja ne pitää tehdä kahteen paikkaan — tai jättää vanhasta kokonaan pois, mikä turhauttaa käyttäjiä.
• Pitkä aika ilman hyötyä. Kuukausien työ, jonka tulosta käyttäjä ei näe. Jos budjetti tai kärsivällisyys loppuu kesken, jäljelle jää keskeneräinen uusi järjestelmä ja yhä se vanha.
• Tietojen siirto. Kymmenen vuoden data on aina sotkuisempaa kuin kukaan arvaa: rikkinäisiä tietueita, tuplasti tallennettuja asiakkaita, kenttiä, joita käytetään johonkin muuhun kuin alkuperäiseen tarkoitukseen.
• Kaikki tai ei mitään. Eräänä päivänä vaihdetaan, ja jos jokin ei toimi, takaisin ei ole minne palata.

Mitä vaiheittainen modernisointi tarkoittaa

Toinen tie on pitää sovellus käytössä ja vaihtaa sen osat yksi kerrallaan. Näin toimin myös palauttamieni vanhojen sovellusten kanssa:

1. Ensin ymmärrys. Sovellus käynnistetään erillisessä ympäristössä ja käydään läpi: versiot, riippuvuudet, missä data on ja mikä on kriittistä.
2. Testit ennen muutoksia. Tärkeimmät työnkulut katetaan testeillä, jotka varmistavat, että sovellus toimii täsmälleen kuten ennenkin. Ne ovat turvaverkko kaikelle sitä seuraavalle.
3. Versiot yksi kerrallaan. Kieli, sovelluskehys, kirjastot ja tietokanta siirretään uudempiin versioihin komponentti kerrallaan. Jokainen askel on pieni, testattava ja tarvittaessa peruttavissa.
4. Toiminnallisuus säilyy. Käyttäjälle mikään ei muutu — sama työnkulku, samat tiedot, vain nopeampana ja turvallisena.
5. Sitten uutta. Vasta kun perusta on moderni, kehitetään uusia ominaisuuksia. Ne ovat taas järkevän hintaisia, koska koodi on luettavaa ja testit suojaavat sitä.

Suurin etu on se, että hyöty tulee heti ja riski pysyy pienenä. Jokainen vaihe päättyy toimivaan järjestelmään. Jos budjetti jossain vaiheessa loppuu, sovellus on silti paremmassa kunnossa kuin alussa.

Rehelliset kriteerit: milloin modernisoida, milloin uusia

Vastaus riippuu viidestä asiasta.

Liiketoimintalogiikan arvo. Jos sovelluksessa on paljon juuri teidän yrityksellenne ominaista logiikkaa — laskentasääntöjä, erikoistapauksia, työnkulkuja —, se puoltaa vahvasti modernisointia. Jos kyse on käytännössä yksinkertaisesta tiedonsyöttölomakkeesta, menetettävää on vähän.

Koodin laatu. Vanha ei tarkoita huonoa. Kymmenen vuotta sitten huolellisesti kirjoitettu koodi on usein hyvin päivitettävissä. Jos koodi taas on sekaisin — tietokantakyselyt keskellä HTML:ää, sama logiikka kopioituna kymmeneen paikkaan —, jokainen askel tulee kalliiksi.

Tiedot. Data elää lähes aina pidempään kuin koodi. Jos tietomalli on järkevä, sen päälle voi rakentaa kummallakin tiellä. Jos tietomalli itse on ongelma, se pitää ratkaista joka tapauksessa.

Budjetti ja aikataulu. Vaiheittaisen modernisoinnin voi jakaa osiin ja keskeyttää. Uusi rakentaminen vaatii yleensä koko summan ennen kuin mitään on käytössä.

Riski. Jos sovelluksen katko maksaa rahaa tai pysäyttää ihmisten työt, vaiheittainen tie on lähes aina turvallisempi.

Milloin uusi järjestelmä on oikeasti halvempi

On tilanteita, joissa sanon itse, ettei modernisointi kannata:

• Tekniikka on niin kuollut, ettei uudempia versioita tai työkaluja ole, ja jokainen komponentti pitäisi joka tapauksessa kirjoittaa uudelleen.
• Liiketoiminta on muuttunut niin paljon, että vanha sovellus ratkaisee ongelmaa, jota ei enää ole.
• Sovellus on pieni ja sen logiikka mahtuu parille sivulle — silloin uuden kirjoittaminen on nopeampaa kuin vanhan purkaminen.
• Valmis alusta kattaa tarpeen. Esimerkiksi verkkokauppaa, varastoa ja ajanvarausta varten ei usein kannata rakentaa omaa järjestelmää, kun NUNDINAE-tyyppinen ratkaisu on jo olemassa.

Silloinkin vanha järjestelmä kannattaa analysoida ennen uuden aloittamista — nimenomaan, jotta piilossa olevat liiketoimintasäännöt saadaan kirjattua.

Jos vanha järjestelmä onkin verkkosivusto, periaate on sama: uudistus onnistuu, mutta niin, ettei jo toimivaa menetetä. Kirjoitin siitä erikseen artikkelissa sivustouudistuksesta ja hakukonenäkyvyydestä.

Miten aloitan

Ensimmäinen askel on aina katselmointi: käyn läpi sovelluksen, versiot, tiedot ja palvelimen ja kerron kirjallisesti, mitä näen. Siitä tulee myös vastaus pääkysymykseen — modernisoida vai uusia — perusteluineen. Jos sovelluksessa on luottamuksellista tietoa, salassapitosopimus on täysin tavallinen asia.

Lisää siitä, mitä ja miten teen, löydät ohjelmistojen modernisoinnin sivulta.

Onko sinulla sovellus, johon kukaan ei uskalla koskea? Kuvaile tilanteesi parilla lauseella tässä — mikä järjestelmä on kyseessä, kuinka vanha ja mikä nyt huolettaa. Vastaan yhden työpäivän kuluessa ja kerron rehellisesti, voinko auttaa ja miten. Jos haluat mieluummin vain kirjoittaa, kaikki yhteystiedot ovat yhteystietosivulla.

Pitääkö sovelluksen olla poissa käytöstä modernisoinnin ajan?

Yleensä ei. Työ tehdään erillisessä ympäristössä, ja tuotantoversio vaihdetaan vasta, kun uusi on testattu. Vaihto on lyhyt ja suunniteltu.

Entä jos alkuperäistä kehittäjää tai dokumentaatiota ei ole?

Se on pikemminkin sääntö kuin poikkeus. Koodi itse on dokumentaatio — sen lukemiseen pitää vain varata aikaa. Alussa kirjoitetut testit kuvaavat samalla, miten sovellus todella toimii.

Voiko sovellusta kehittää modernisoinnin jälkeen eteenpäin?

Kyllä, se on koko tarkoitus. Kun perusta on moderni ja testien kattama, uusia ominaisuuksia voi lisätä samaan tapaan kuin uuteen sovellukseen.