S modernizací starší aplikace začněte tím, že sepíšete, proč se musí změnit, a pak posuďte kód i produkci dohromady. Než změníte strukturu, stabilizujte systém a obalte testy chování, na kterém firma závisí. S touto záchrannou sítí nahrazujte systém po částech, data přesouvejte promyšleně a úplné přepsání si nechte pro vzácný případ, kdy se nevyplatí téměř nic zachovat.
Než se dotknete kódu, pojmenujte obchodní důvod
Modernizace je drahá, takže začněte důvodem. Běžné důvody jsou běhové prostředí nebo framework po konci podpory, změny, které trvají týdny, protože každé vydání něco rozbije, systém, kterému rozumí jen jeden člověk, nebo platforma, která neunese to, co firma potřebuje dál. Každý důvod ukazuje na jiný první krok.
Důvod sepište spolu s měřítkem, které můžete později ověřit, například jak často vydáváte, kolik máte incidentů nebo jak dlouho trvá, než se běžná změna dostane k uživatelům. Bez něj se modernizace stane technickým projektem bez konce, který se při další revizi rozpočtu těžko obhajuje.
Než cokoli rozhodnete, posuďte kód i produkci
Posouzení vám řekne, co skutečně máte. Udržte ho krátké a zakončete ho písemnou zprávou a doporučeným prvním krokem. Čtěte kód, ale čtěte i produkci: logy, incidenty, pomalé dotazy a způsob, jakým se vydává. Nejhorší problémy často leží kolem kódu, ne v něm.
- Verze běhového prostředí, frameworku a knihoven a které z nich už nedostávají bezpečnostní opravy
- Které části se mění nejčastěji a které se nejčastěji rozbíjejí, podle historie verzí a záznamů o incidentech
- Pokrytí testy u cest, na kterých firma závisí
- Jak se aplikace sestavuje, konfiguruje a nasazuje a kdo to umí
- Datový model, jeho velikost a které další systémy čtou stejnou databázi nebo do ní zapisují
- Lidé, kteří systém znají, a co vědí jen oni
Nejdřív stabilizujte produkci, aby práce měla pevný základ
Pokud systém každý týden selže, modernizace se bude každý týden přerušovat. Nejdřív opravte to, co způsobuje incidenty: přidejte monitoring a upozornění na kritické cesty, automatizujte sestavení a nasazení, aby byla vydání opakovatelná, a vyjměte tajné klíče a konfiguraci z kódu.
Tyto kroky se vyplatí okamžitě a každý další krok dělají bezpečnějším. Navíc brzy ukážou, zda tým dokáže systém měnit, aniž by ho rozbil, a to je dobré vědět dřív, než se zavážete k většímu plánu.
Obalte chování, na které spoléháte, záchrannou sítí z testů
Starší kód mívá málo testů a jeho zdokumentované chování jen zřídka odpovídá skutečnému. Než změníte strukturu, napište charakterizační testy: testy, které zaznamenají, co systém dělá dnes, včetně jeho podivných hraničních případů, takže každá změna chování se projeví jako neúspěšný test.
Začněte na okrajích, testy, které volají aplikaci přes její API nebo uživatelské rozhraní a kontrolují výsledky, protože ty přežijí vnitřní změny. U výpočtů a reportů přehrajte skutečné vstupy starým i novým kódem a porovnejte výstupy. Jemnější testy přidávejte do každé části ve chvíli, kdy ji refaktorujete. Náš článek o upgradu kritické aplikace v Javě 8 ukazuje stejnou záchrannou síť použitou při upgradu běhového prostředí.
Nahrazujte systém po částech, místo abyste ho přepisovali
Úplné přepsání vypadá na papíře čistě, jenže starý systém mezitím dál běží a mění se, zatímco nový ho dohání, a každé nezdokumentované chování je třeba cestou znovu objevit. Proto přepsání tak často trvá déle, než se plánovalo, a firma čeká.
Obvyklou alternativou je vzor strangler fig (škrticí fíkovník). Před starší aplikaci předřaďte směrovací vrstvu, například reverzní proxy nebo API gateway. V novém kódu budujte jednu funkci po druhé a jakmile se osvědčí, směrujte na ni provoz pro danou funkci. Starý systém se zmenšuje, až ho lze vypnout, a firma získává hodnotu v každém kroku.
Přepsání přesto může být správná volba: když je kódová základna malá a jejímu chování se dobře rozumí, nebo když platformu, na které běží, nelze udržet při životě dost dlouho na postupnou náhradu. Rozhodujte podle sepsaných kritérií, ne z frustrace.
S daty zacházejte jako se samostatnou migrací
Kód lze nahrazovat po částech, data se dělí hůř. Dokud starší a nový kód sdílejí jednu databázi, musí se každá změna schématu koordinovat. Včas rozhodněte, který systém je pro jednotlivé druhy dat zdrojem pravdy, a vyhněte se tomu, aby dva systémy zapisovaly stejný záznam bez pravidla, který zápis vyhrává.
Když se funkce přesouvá, přesuňte nebo synchronizujte její data promyšleně: migračními skripty otestovanými na kopii produkce, nebo průběžnou synchronizací, dokud běží oba systémy. Naplánujte, jak oba systémy sladíte, například denními počty a kontrolními součty, a zachovejte si možnost přepnout zpět, dokud čísla nesedí.
Práci řaďte podle rizika a přínosu a ukažte pokrok brzy
Práci seřaďte tak, aby každý krok buď snížil riziko, nebo přinesl něco, co firma uvidí. Běžné pořadí je stabilizovat a automatizovat, přidat testy, upgradovat běhové prostředí a pak vyčlenit funkce, které se mění nejčastěji. Stabilní a málokdy měněné části mohou počkat, někdy i natrvalo.
Plán držte krátký a po každém kroku ho revidujte, protože to, co se dozvíte, pořadí změní. Naši inženýři takto pracovali na kritických systémech. Přes Sopra Steria vedli migraci kritické aplikace pro denní obchodování s plynem z Javy 8 na 16 a jako součást programového týmu cloudového programu Crédit Agricole jsme u každé aplikace, kterou jsme migrovali, posoudili, zda ji upgradovat, nebo přestavět. Pokud chcete posoudit vlastní systém nebo tým, který plán provede, SDK Enterprises dělá obojí v rámci jedné smlouvy.
Hlavní body
- Sepište obchodní důvod modernizace spolu s měřítkem, které můžete později ověřit.
- Než zvolíte mezi upgradem, postupnou náhradou a přepsáním, posuďte kód i produkci dohromady.
- Než změníte strukturu, stabilizujte produkci a obalte kritické chování charakterizačními testy.
- Nahrazujte systém po částech za směrovací vrstvou, pokud přepsání není zjevně menší a bezpečnější.
- Vlastnictví dat, synchronizaci a jejich sladění plánujte jako samostatnou migraci.
Časté dotazy
Máme starší aplikaci přepsat od nuly?
Obvykle ne. Přepsání soupeří se systémem, který se dál mění, a musí znovu objevit chování, které nikdo nezdokumentoval. Nahrazujte postupně, pokud kódová základna není malá a dobře pochopená, nebo svázaná s platformou, kterou nelze udržet v provozu.
Jak dlouho trvá modernizace starší aplikace?
Záleží na velikosti systému, pokrytí testy, na tom, jak zamotaná jsou jeho data a kolik se toho musí změnit. Krátké posouzení vám dá realistický plán a první krok dost malý na to, abyste ho dokončili a změřili, místo jednoho termínu pro celé úsilí.
Můžeme během modernizace dál vydávat nové funkce?
Ano a měli byste. Postupná náhrada umožňuje týmu dodávat funkce v novém kódu, zatímco starší systém dál běží. Dohodněte se, kolik času týmu půjde na modernizaci, aby ho práce na funkcích potichu nepohltila.