Vana tarkvara: uuendada või ehitada uuesti?

Olukord on tuttav: rakendus, millega ettevõte iga päev töötab, on kirjutatud kümme või rohkem aastat tagasi. Ta töötab, aga keegi ei julge teda puutuda. Algne arendaja on ammu läinud, raamistiku versioon on toeta jäänud, server vajab uuendust, mida rakendus ei kannata, ja iga väike muudatus võtab nädalaid.

Siis tuleb laua peale küsimus: kas parandada vana või visata minema ja ehitada uus?

Olen viimastel aastatel taastanud mitu üle kümne aasta vanust rakendust nii riigi- kui erasektoris. Ühegi puhul ei olnud vastus „viska minema“. Aga see ei tähenda, et uus ehitus oleks alati vale — mõnikord on see tõesti odavam. Allpool on kriteeriumid, mille järgi ma seda otsust teen.

Miks „ehitame kõik uuesti“ tundub nii ahvatlev

Vana koodi lugemine on raske ja uue kirjutamine on lõbus. Uus projekt lubab puhast lehte: kaasaegne tehnoloogia, korralik struktuur, kõik see, mis vanas on valesti.

Probleem on selles, et vana rakendus ei ole ainult kood. Ta on kümne aasta jagu ärireegleid. Iga imelik if-lause, mida keegi enam ei mõista, on tõenäoliselt kunagi lisatud põhjusega: erijuhtum mõne kliendi jaoks, seadusemuudatus, raamatupidaja palve, viga, mis tekkis ühel aastavahetusel. Neid reegleid ei ole kirjas üheski dokumendis. Nad on ainult koodis.

Kui rakendus ehitatakse nullist, tuleb kõik need reeglid uuesti avastada — tavaliselt alles siis, kui uus süsteem on kasutusse võetud ja midagi läheb valesti.

Miks suur ümberkirjutus sageli ebaõnnestub

Suurel ümberkirjutusel on paar tüüpilist lõksu, mis korduvad peaaegu igas projektis:

• Liikuv sihtmärk. Uue süsteemi ehitamise ajal vana ei seisa. Äri vajab muudatusi edasi, ja need tuleb teha kahes kohas — või vanas üldse mitte, mis tekitab kasutajates pahameelt.
• Pikk aeg ilma väärtuseta. Kuude kaupa tööd, mille tulemust kasutaja ei näe. Kui eelarve või kannatus enne lõppu otsa saab, jääb alles pooleli uus süsteem ja endiselt vana.
• Andmete kolimine. Kümne aasta andmed on alati mustemad, kui keegi arvab. Vigased kirjed, topeltkliendid, väljad, mida kasutatakse algse otstarbe asemel millekski muuks.
• Kõik või mitte midagi. Ühel päeval lülitatakse ümber ja kui midagi ei tööta, ei ole kuhugi tagasi minna.

Mida uuendamine samm-sammult tähendab

Teine tee on hoida rakendus töös ja vahetada tema osad välja ükshaaval. Nii tegin ka nende vanade rakenduste puhul, mida olen taastanud:

1. Kõigepealt arusaamine. Rakendus pannakse käima eraldi keskkonnas ja vaadatakse üle: mis versioonid, mis sõltuvused, kus on andmed, mis on kriitiline.
2. Testid enne muudatusi. Kõige olulisemad tööprotsessid kaetakse testidega, mis kontrollivad, et rakendus käitub täpselt nii nagu enne. Need on turvavõrk kõigele järgnevale.
3. Versioonid ükshaaval. Keel, raamistik, teegid ja andmebaas viiakse uuematele versioonidele komponent haaval. Iga samm on väike, testitav ja vajadusel tagasi pööratav.
4. Funktsionaalsus säilib. Kasutaja jaoks ei muutu midagi — sama töövoog, samad andmed, ainult kiirem ja turvaline.
5. Siis uued asjad. Alles kui alus on kaasaegne, arendatakse juurde uut funktsionaalsust. Nüüd on see taas mõistliku hinnaga, sest kood on loetav ja testid kaitsevad.

Selle lähenemise suurim eelis on, et väärtus tuleb kohe ja risk on väike. Iga etapp lõppeb töötava süsteemiga. Kui eelarve mingil hetkel lõpeb, on rakendus ikkagi paremas seisus kui alguses.

Ausad kriteeriumid: millal uuendada, millal ehitada uuesti

Vastus sõltub viiest asjast.

Äriloogika väärtus. Kui rakendus sisaldab palju ettevõttele omast loogikat — arvestusreegleid, erijuhtumeid, töövooge —, kaalub see tugevalt uuendamise poole. Kui ta on sisuliselt lihtne andmete sisestamise vorm, on kaotada vähe.

Koodi kvaliteet. Vana ei tähenda halba. Kümme aastat tagasi korralikult kirjutatud kood on tihti hästi uuendatav. Kui aga kood on segamini — andmebaasipäringud keset HTML-i, sama loogika kopeeritud kümnesse kohta —, läheb iga samm kalliks.

Andmed. Andmed elavad peaaegu alati kauem kui kood. Kui andmemudel on mõistlik, saab selle peale ehitada mõlemal teel. Kui andmemudel on ise probleem, tuleb see lahendada igal juhul.

Eelarve ja ajaraam. Samm-sammult uuendamist saab jagada etappideks ja peatada. Uus ehitus nõuab üldjuhul kogu summat enne, kui midagi kasutusse jõuab.

Risk. Kui rakenduse seisak maksab raha või tähendab, et inimesed ei saa tööd teha, on järkjärguline tee peaaegu alati turvalisem.

Millal on uus ehitus tegelikult odavam

On olukordi, kus ütlen ise, et uuendada ei tasu:

• Tehnoloogia on nii surnud, et sellele ei ole enam uuemat versiooni ega tööriistu ning iga komponent tuleks niikuinii ümber kirjutada.
• Äri on muutunud nii palju, et vana rakendus lahendab probleemi, mida enam ei ole.
• Rakendus on väike ja selle loogika mahub paarile lehele — siis on uus kirjutamine kiirem kui vana lahtiharutamine.
• Valmis platvorm katab vajaduse. Näiteks e-poe, lao ja broneeringute jaoks ei ole tihti mõtet eraldi süsteemi ehitada, kui olemas on lahendus nagu NUNDINAE.

Ka siis tasub vana süsteemi analüüsida enne, kui midagi uut alustatakse — just selleks, et need peidetud ärireeglid kirja saada.

Kui vana süsteem on hoopis koduleht, kehtib sama põhimõte: uus ehitus on võimalik, aga seda tuleb teha nii, et olemasolev väärtus ei kaoks. Sellest kirjutasin eraldi postituses kodulehe uuendamisest ilma positsioone kaotamata.

Kuidas ma tööd alustan

Esimene samm on alati ülevaatus: vaatan rakenduse, versioonid, andmed ja serveri üle ning ütlen kirjalikult, mida näen. Sealt tuleb ka vastus põhiküsimusele — uuendada või ehitada uuesti — koos põhjendusega. Kui rakendus sisaldab konfidentsiaalset infot, on konfidentsiaalsusleping tavaline asi.

Rohkem selle kohta, mida teen ja kuidas, leiad tarkvara uuendamise ja edasiarenduse lehelt.

Kas sul on rakendus, mida keegi ei julge puutuda? Kirjelda oma olukorda paari lausega siin — mis süsteem see on, kui vana ja mis praegu muret teeb. Vastan ühe tööpäeva jooksul ja ütlen ausalt, kas ja kuidas saan aidata. Kui eelistad lihtsalt kirjutada, leiad kõik kontaktid kontaktilehelt.

Kas uuendamise ajal peab rakendus seisma?

Üldjuhul mitte. Töö käib eraldi keskkonnas ja töös olev versioon vahetatakse alles siis, kui uus on testitud. Ümberlülitus on lühike ja planeeritud.

Mis siis, kui algset arendajat ega dokumentatsiooni ei ole?

See on pigem reegel kui erand. Kood ise on dokumentatsioon — tuleb lihtsalt aega võtta, et seda lugeda. Testid, mis alguses kirjutatakse, kirjeldavad ühtlasi, kuidas rakendus päriselt käitub.

Kas peale uuendamist saab edasi arendada?

Jah, see ongi eesmärk. Kui alus on kaasaegne ja testidega kaetud, saab uut funktsionaalsust lisada samamoodi nagu uude rakendusse.