Vanhan sovelluksen modernisointi alkaa siitä, että kirjaat ylös, miksi sen on muututtava, ja arvioit koodin ja tuotannon yhdessä. Vakauta järjestelmä ja rakenna testit liiketoiminnan kannalta tärkeän toiminnan ympärille ennen kuin muutat sen rakennetta. Kun turvaverkko on paikallaan, korvaa järjestelmä pala palalta, siirrä tiedot harkiten ja jätä täydellinen uudelleenkirjoitus harvinaiseen tapaukseen, jossa säilyttämisen arvoista on vähän.
Nimeä liiketoiminnallinen syy ennen kuin kosket koodiin
Modernisointi on kallista, joten aloita syystä. Yleisiä syitä ovat ajoympäristö tai sovelluskehys, jonka tuki on päättynyt, muutokset, jotka vievät viikkoja, koska jokainen julkaisu rikkoo jotain, järjestelmä, jota vain yksi ihminen ymmärtää, tai alusta, joka ei pysty tukemaan liiketoiminnan seuraavia tarpeita. Jokainen syy osoittaa eri ensimmäiseen askeleeseen.
Kirjaa syy ylös mittarin kanssa, jonka voit tarkistaa myöhemmin, kuten julkaisutiheys, häiriöiden määrä tai se, kuinka kauan tyypillisellä muutoksella kestää päästä käyttäjille. Ilman sitä modernisoinnista tulee loputon tekninen projekti, jota on vaikea puolustaa seuraavassa budjettikatselmuksessa.
Arvioi koodi ja tuotanto ennen kuin päätät mitään
Arvio kertoo, mitä sinulla oikeasti on. Pidä se lyhyenä ja päätä se kirjalliseen raporttiin ja suositeltuun ensimmäiseen askeleeseen. Lue koodi, mutta lue myös tuotanto: lokit, häiriöt, hitaat kyselyt ja tapa, jolla julkaisut tehdään. Pahimmat ongelmat ovat usein koodin ympärillä eivätkä siinä itsessään.
- Ajoympäristön, sovelluskehyksen ja kirjastojen versiot sekä se, mitkä niistä eivät enää saa tietoturvapäivityksiä
- Mitkä osat muuttuvat useimmin ja mitkä hajoavat useimmin, versiohistorian ja häiriölokin perusteella
- Testikattavuus liiketoiminnan kannalta tärkeillä poluilla
- Miten sovellus käännetään, konfiguroidaan ja otetaan käyttöön, ja kuka siihen pystyy
- Tietomalli, sen koko ja se, mitkä muut järjestelmät lukevat tai kirjoittavat samaan tietokantaan
- Ihmiset, jotka tuntevat järjestelmän, ja se, mitä vain he tietävät
Vakauta tuotanto ensin, jotta työllä on vakaa pohja
Jos järjestelmä kaatuu joka viikko, modernisointi keskeytyy joka viikko. Korjaa ensin häiriöiden syyt: lisää valvonta ja hälytykset kriittisille poluille, automatisoi käännös ja käyttöönotto, jotta julkaisut ovat toistettavia, ja siirrä salaisuudet ja asetukset pois koodista.
Nämä askeleet maksavat itsensä takaisin heti ja tekevät jokaisesta myöhemmästä askeleesta turvallisemman. Ne osoittavat myös varhain, pystyykö tiimi muuttamaan järjestelmää rikkomatta sitä, mikä on hyvä tietää ennen sitoutumista laajempaan suunnitelmaan.
Rakenna testien turvaverkko sen toiminnan ympärille, johon luotat
Vanhassa koodissa on yleensä vähän testejä, ja sen dokumentoitu toiminta vastaa harvoin todellista. Kirjoita ennen rakenteen muuttamista karakterisointitestit: testit, jotka tallentavat, mitä järjestelmä tekee nyt, myös sen oudot reunatapaukset, jotta mikä tahansa toiminnan muutos näkyy epäonnistuvana testinä.
Aloita reunoilta testeillä, jotka kutsuvat sovellusta sen API:n tai käyttöliittymän kautta ja tarkistavat tulokset, koska ne kestävät sisäiset muutokset. Laskelmissa ja raporteissa aja oikeat syötteet vanhan ja uuden koodin läpi ja vertaa tuloksia. Lisää hienojakoisempia testejä kuhunkin osaan sitä mukaa kuin refaktoroit sitä. Artikkelimme kriittisen Java 8 -sovelluksen päivittämisestä näyttää saman turvaverkon ajoympäristön päivityksessä.
Korvaa järjestelmä pala palalta uudelleenkirjoittamisen sijaan
Täydellinen uudelleenkirjoitus näyttää paperilla siistiltä, mutta vanha järjestelmä toimii ja muuttuu edelleen, kun uusi yrittää saada sen kiinni, ja jokainen dokumentoimaton toiminto on löydettävä matkan varrella uudelleen. Siksi uudelleenkirjoitukset kestävät niin usein suunniteltua kauemmin, kun liiketoiminta odottaa.
Tavallinen vaihtoehto on kuristajaviikunamalli (strangler fig). Aseta vanhan sovelluksen eteen reitityskerros, kuten käänteinen välityspalvelin (reverse proxy) tai API-yhdyskäytävä. Rakenna yksi kyvykkyys kerrallaan uuteen koodiin ja ohjaa sen liikenne sinne, kun se on todettu toimivaksi. Vanha järjestelmä kutistuu, kunnes sen voi sammuttaa, ja liiketoiminta saa arvoa jokaisessa vaiheessa.
Uudelleenkirjoitus voi silti olla oikea ratkaisu: kun koodikanta on pieni ja sen toiminta hyvin ymmärretty tai kun alustaa, jolla se toimii, ei voida pitää hengissä tarpeeksi kauan asteittaista korvaamista varten. Päätä kirjallisten kriteerien, älä turhautumisen perusteella.
Käsittele tietoja omana siirtonaan
Koodin voi korvata viipaleittain; tietoja on vaikeampi jakaa. Niin kauan kuin vanha ja uusi koodi jakavat yhden tietokannan, jokainen skeemamuutos on koordinoitava. Päätä varhain, mikä järjestelmä on kunkin tietotyypin totuuden lähde, ja vältä tilannetta, jossa kaksi järjestelmää kirjoittaa samaa tietuetta ilman sääntöä siitä, kumman kirjoitus voittaa.
Kun kyvykkyys siirtyy, siirrä tai synkronoi sen tiedot harkiten: tuotannon kopiota vasten testatuilla siirtoskripteillä tai jatkuvalla synkronoinnilla, kun molemmat järjestelmät ovat käynnissä. Suunnittele, miten täsmäytät nämä kaksi, esimerkiksi päivittäisillä määrillä ja tarkistussummilla, ja säilytä mahdollisuus palata takaisin, kunnes luvut täsmäävät.
Järjestä työ riskin ja arvon mukaan ja näytä edistystä varhain
Järjestä työ niin, että jokainen askel joko vähentää riskiä tai tuottaa jotain, minkä liiketoiminta näkee. Yleinen järjestys on vakauttaa ja automatisoida, lisätä testit, päivittää ajoympäristö ja sitten irrottaa useimmin muuttuvat kyvykkyydet. Vakaat ja harvoin muutettavat osat voivat odottaa, joskus loputtomiin.
Pidä suunnitelma lyhyenä ja tarkista se jokaisen askeleen jälkeen, koska oppimasi muuttaa järjestystä. Kehittäjämme ovat työskennelleet näin kriittisten järjestelmien parissa. Sopra Sterian kautta he johtivat kriittisen kaasun päiväkauppasovelluksen siirron Java 8:sta Java 16:een, ja Crédit Agricolen pilviohjelman tiimin osana arvioimme jokaisen siirtämämme sovelluksen päättääksemme, päivitetäänkö se vai rakennetaanko se uudelleen. Jos haluat arvion omasta järjestelmästäsi tai tiimin toteuttamaan suunnitelman, SDK Enterprises tekee molemmat yhdellä sopimuksella.
Tärkeimmät havainnot
- Kirjaa modernisoinnin liiketoiminnallinen syy ylös mittarin kanssa, jonka voit tarkistaa myöhemmin.
- Arvioi koodi ja tuotanto yhdessä ennen kuin valitset päivityksen, asteittaisen korvaamisen ja uudelleenkirjoituksen välillä.
- Vakauta tuotanto ja rakenna karakterisointitestit kriittisen toiminnan ympärille ennen rakenteen muuttamista.
- Korvaa järjestelmä pala palalta reitityskerroksen takana, ellei uudelleenkirjoitus ole selvästi pienempi ja turvallisempi.
- Suunnittele tietojen omistajuus, synkronointi ja täsmäytys omana siirtonaan.
UKK
Kannattaako vanha sovellus kirjoittaa kokonaan uudelleen?
Yleensä ei. Uudelleenkirjoitus kilpailee järjestelmän kanssa, joka muuttuu jatkuvasti, ja sen on löydettävä uudelleen toiminta, jota kukaan ei dokumentoinut. Korvaa järjestelmä asteittain, ellei koodikanta ole pieni ja hyvin ymmärretty tai sidottu alustaan, jota ei voida pitää käynnissä.
Kuinka kauan vanhan sovelluksen modernisointi kestää?
Se riippuu järjestelmän koosta, sen testikattavuudesta, siitä, kuinka sotkuiset sen tiedot ovat, ja siitä, kuinka paljon on muututtava. Lyhyt arvio antaa yhden koko hankkeen päivämäärän sijaan realistisen suunnitelman ja ensimmäisen askeleen, joka on tarpeeksi pieni saatettavaksi loppuun ja mitattavaksi.
Voimmeko jatkaa uusien ominaisuuksien julkaisemista modernisoinnin aikana?
Kyllä, ja niin kannattaakin. Asteittainen korvaaminen antaa tiimin toimittaa ominaisuuksia uudessa koodissa, kun vanha järjestelmä on edelleen käynnissä. Sovi, kuinka suuri osa tiimin ajasta käytetään modernisointiin, jottei ominaisuustyö huomaamatta vie sitä.