Milloin refaktorointi on parempi vaihtoehto kuin uudelleenkirjoitus?
Vaiheittainen refaktorointi on usein järkevämpi, kun nykyinen järjestelmä tukee edelleen tärkeää liiketoimintaa ja sen ongelmat voidaan rajata. Uudelleenkirjoitus voi olla perusteltu, jos arkkitehtuuri estää tarvittavan muutoksen, ylläpito on kohtuuttoman vaikeaa tai alusta ei enää täytä vaatimuksia. Vertailkaa kokonaiskustannuksia, toimitusaikaa, siirtymäriskiä ja todellista liiketoimintahyötyä—älkää vain koodin ikää tai arkkitehtuurin nimeä.
Monoliitti ei ole automaattisesti huono, eikä mikropalvelu automaattisesti nopeampi tai halvempi. Monoliittinen järjestelmä voi olla hyvin ylläpidetty ja vastata liiketoiminnan tarpeisiin. Huonosti rajattu mikropalveluarkkitehtuuri voi puolestaan lisätä verkko-, valvonta-, tietoturva- ja päivystyskuormaa. Päätöksen pitäisi lähteä todetusta rajoitteesta, kuten hitaista julkaisuista, epäluotettavasta testauksesta, kasvavasta häiriöriskistä tai tuoteominaisuuksien korkeasta läpimenoajasta.
Vertaa kokonaiskustannuksia ja siirtymäriskiä
Uudelleenkirjoitus vaikuttaa houkuttelevalta, koska se lupaa puhtaan alun. Budjettiin on kuitenkin sisällytettävä sekä uuden järjestelmän rakentaminen että vanhan toiminnan ylläpito siirtymän aikana. Lisäksi on huomioitava toiminnallisuuksien kartoittaminen, datan siirto, vanhojen poikkeusten selvittäminen, integraatioiden yhteensopivuus, käyttäjien koulutus ja rinnakkaisajon kustannukset.
Myös vaiheittaisella refaktoroinnilla on kustannuksia: tiimi ylläpitää väliaikaisesti sekä vanhaa että uutta toteutusta, rajapintakerros tuo työtä ja riippuvuuksien selvittäminen voi viedä aikaa. Hyöty voi kuitenkin alkaa aikaisemmin, kun rajattu toiminto siirretään ja parannus saadaan käyttöön ilman koko järjestelmän odottamista. Se myös tuottaa näyttöä siitä, toimivatko arkkitehtuurivalinnat kyseisessä ympäristössä.
Vertailkaa vaihtoehtoja elinkaaren kokonaiskustannuksella. Sisällyttäkää kehitys, pilvi- tai alustakustannukset, testaus, siirto, tietoturva, operointi, koulutus ja muutosriskin hallinta. Määrittäkää ennen investointia, millä mittarilla hyöty arvioidaan: esimerkiksi ominaisuuden toimitusaika, häiriöiden vaikutus, muutoksen kustannus tai tuetun liiketoimintaprosessin läpimeno.
Tunnista, mikä todella estää kehitystä
Kerätkää näyttöä julkaisuista, muutoksista, häiriöistä, rakennusajoista ja käyttäjäpalautteesta. Selvittäkää, johtuuko ongelma järjestelmän sisäisestä kytkeytyneisyydestä vai puuttuvasta testikattavuudesta, epäselvistä omistajista, hitaasta hyväksyntäprosessista tai ulkoisesta toimittajariippuvuudesta. Uusi arkkitehtuuri ei itsessään korjaa prosessia, jossa muutoksia ei voida testata tai hyväksyä.
Kartoitus voi paljastaa, että yksi osa-alue—kuten raportointi, tunnistautuminen tai asiakasintegraatio—aiheuttaa suhteettoman paljon työtä. Aloittakaa rajasta, jossa muutos vaikuttaa mitattavasti, data ja omistajuus ovat ymmärrettävissä ja järjestelmä voidaan säilyttää toimivana siirron aikana.
Mikropalvelu kannattaa ottaa käyttöön vain, jos erillisestä julkaisemisesta, skaalauksesta, omistajuudesta tai vikojen rajaamisesta on todellinen hyöty. Palvelu tarvitsee rajapinnan lisäksi valvonnan, hälytykset, käyttöoikeudet, tietojen käsittelyn ja selkeän operointivastuun. Jos näitä kyvykkyyksiä ei ole, uuden palvelun ylläpitokustannus voi ylittää sen tuoman hyödyn.
Arkkitehtuurin pilkkominen ei myöskään poista riippuvuuksia: se muuttaa niiden muotoa. Prosessi, joka aiemmin käytti yhden tietokantatransaktion, voi palvelurajojen jälkeen vaatia idempotenssia, uudelleenyrityksiä, tapahtumien käsittelyä ja täsmäytystä. Tiimin on osattava seurata pyyntöä usean palvelun läpi ja ratkaista osittainen epäonnistuminen. Nämä kyvykkyydet kuuluvat uudistuksen kustannusmalliin.
Jos julkaisut ovat hitaita, etsikää myös työnkulun pullonkauloja: käsin tehtävät hyväksynnät, puuttuvat automaattitestit ja vaikeasti palautettavat muutokset voivat hidastaa monoliittia riippumatta siitä, jaetaanko se palveluihin. Automatisoidut testit ja ennakoitava julkaisutapa voivat parantaa toimitusta ennen arkkitehtuurin laajaa muutosta.
Refaktoroi vaiheittain ja säilytä palautusreitti
Martin Fowlerin kuvaama Strangler Fig -malli käsittelee järjestelmän korvaamista vähitellen sen reunoilta. Käytännössä uusi toiminto voidaan ottaa käyttöön sovitun rajapinnan takana, kun vanha järjestelmä käsittelee vielä muuta liiketoimintaa. Tämän mallin käyttö vaatii kuitenkin reitityksen, datan, identiteetin ja virhetilanteiden suunnittelua.
Ennen siirtoa dokumentoikaa nykyinen käyttäytyminen ja lisätkää testit kriittisille säännöille. Sopikaa, miten liikenne ohjataan uuteen toteutukseen, miten tietojen eheys tarkistetaan ja miten muutos perutaan. Käyttäkää vaiheistettua käyttöönottoa, jos järjestelmä ja ympäristö sen sallivat. Seuratkaa liiketoiminnan tulosta, suorituskykyä ja häiriöitä—pelkkä palvelun onnistunut käynnistys ei todista siirtoa onnistuneeksi.
Välttäkää uuden ja vanhan järjestelmän ristiriitaisia kirjoituksia samaan tietoon. Määrittäkää, kumpi on kunkin kentän tai prosessin auktoritatiivinen omistaja siirtymän aikana. Sopikaa tietojen synkronoinnista, duplikaattien käsittelystä, auditoinnista ja palautuksesta ennen tuotantoon siirtymistä.
Esimerkkivertailu investointipäätöstä varten
Oletetaan, että tilausten käsittelyä on vaikea muuttaa, mutta laskutus ja varastonhallinta toimivat vakaasti. Täysi uudelleenkirjoitus sisältäisi kaikki kolme aluetta, niiden vanhat poikkeukset, integraatiot ja rinnakkaisen käyttöönoton. Vaiheittainen vaihtoehto voisi ensin erottaa tilausten käsittelylle selkeän rajapinnan, parantaa sen kriittisiä testejä ja siirtää yhden muutoksen kerrallaan.
Ennen päätöstä arvioidaan molemmille vaihtoehdoille samat erät: kehitystyö, vanhan järjestelmän tuki, tiedonsiirto, käyttöönoton riski, koulutus ja uusi operointi. Lisäksi sovitaan mittari, esimerkiksi tilaussäännön muutokseen kuluvat päivät tai virheellisten tilausten määrä. Esimerkki havainnollistaa arviointitapaa, ei tiettyä säästöä tai sijoituksen tuottoa.
Milloin uudelleenkirjoitus voi olla oikea päätös?
Kokonaan uusi toteutus voi olla perusteltu, jos käyttöympäristöä tai ydinkomponentteja ei enää tueta, tietoturvavaatimuksia ei voida täyttää, teknologia ei toimi tarvittavalla alustalla tai liiketoimintamalli on muuttunut niin paljon, että nykyinen järjestelmä ei enää vastaa tarpeita. Näissäkin tapauksissa vaiheittainen siirtymä voi olla turvallisempi kuin kertaluonteinen käyttöönotto.
Uudelleenkirjoituksen perustelun pitäisi sisältää toiminnallinen laajuus, siirtosuunnitelma, integraatioiden yhteensopivuus, tietojen omistajuus, käyttäjien siirtyminen ja vanhan järjestelmän alasajo. Jos laajuus perustuu oletukseen, että uusi koodi automaattisesti poistaa vuosien liiketoimintapoikkeukset, projektin riski on aliarvioitu.
Päätöksen tueksi tehkää lyhyt, edustava kokeilu. Valitkaa osa järjestelmästä, jossa näkyy keskeinen tekninen ja toiminnallinen haaste. Arvioikaa, mitä siirto vaatii ja millä näytöllä työ kannattaa jatkaa. Kokeilun tarkoitus ei ole rakentaa irrallista demoa, vaan tarkistaa suunnittelun, testauksen, integraation ja operoinnin oletuksia.
Käyttäkää päätösvaiheessa vaihtoehtojen vertailuun samanlaista tarkastelujaksoa. Arvioikaa nykyisen järjestelmän ylläpitoa ja muutosten toteutusta myös tulevina vuosina, mutta älkää unohtako uuden ratkaisun jatkuvia pilvi-, valvonta- ja tukikuluja. Diskonttaus, riskipainot ja kustannusarviot vaativat talous- ja liiketoimintajohdon hyväksynnän; tekninen tiimi voi tuottaa oletukset ja herkkyystarkastelun, mutta sen ei pidä esittää epävarmaa hyötyä toteutuneena.
Määritelkää lisäksi pysäytysehdot. Jos kokeilu ei saavuta sovittua laatua, ei pysty palaamaan turvallisesti tai tarvitsee ennakoitua enemmän tietojen yhteensovittamista, vaihtoehto pitää voida arvioida uudelleen. Päätöksen muuttaminen uuden näytön perusteella ei ole epäonnistuminen, vaan osa hallittua modernisointia.
Kun vaihtoehdot arvioidaan yhdessä tuoteomistajien, arkkitehtien ja operoinnin kanssa, myös siirtymätyön omistajuus selkiytyy. Sopikaa, kuka vastaa vanhoista integraatioista, uusien palveluiden valvonnasta ja käyttäjätuesta muutoksen aikana. Ilman tätä suunnitelmaa teknisesti onnistunut refaktorointi voi siirtää kustannuksia tiimiltä toiselle.
Usein kysyttyä
Tarkoittaako monoliitti aina vanhaa teknologiaa?
Ei. Monoliittinen rakenne kuvaa tapaa pakata ja ottaa järjestelmä käyttöön. Hyvin rajattu monoliitti voi olla selkeä ja kustannustehokas; arkkitehtuurivalinta pitää suhteuttaa tuotteen tarpeisiin.
Saako mikropalveluista aina nopeammat julkaisut?
Ei automaattisesti. Erillinen julkaisu voi auttaa, mutta vain jos rajapinnat, testit, valvonta ja palveluomistajuus toimivat. Muuten riippuvuuksien määrä ja operointityö voivat hidastaa tiimejä.
Miten sijoituksen tuottoa arvioidaan?
Kirjatkaa nykyinen kustannus ja toimituksen tai häiriöiden lähtötaso. Verratkaa niitä vaiheistettujen muutosten jälkeen, ja sisällyttäkää rinnakkaiskäyttö, siirto, ylläpito sekä koulutus laskelmaan. Älkää esittäkö ennustetta toteutuneena säästönä.
Perustakaa modernisointi todettuun ongelmaan
Vaiheittainen refaktorointi voi tuottaa hyötyä aiemmin ja pienentää siirtymän riskiä, kun muutos on hyvin rajattu. Uudelleenkirjoitus voi olla oikea ratkaisu, mutta se tarvitsee realistisen siirron, kattavan kustannusmallin ja liiketoiminnan hyväksynnän. FIX Solutions voi auttaa rajaamaan modernisointityötä IT-kehityspalveluiden kautta.