5 signálů, že váš legacy systém potřebuje modernizaci
Otázkou není, jestli systém bude potřebovat modernizaci, ale jestli ji uděláte v klidu, nebo v krizi. Tady je pět signálů, že se čas krátí.
Každý kód stárne. Otázkou není, zda váš systém bude potřebovat modernizaci — ale zda ji provedete proaktivně, nebo v krizi. Zde je pět signálů, že čas se krátí.
Ani jeden z nich není o technologii samotné. Starý systém, který spolehlivě dělá svou práci a nikdo ho nepotřebuje měnit, je v pořádku. Problém začíná ve chvíli, kdy systém stojí v cestě tomu, co firma chce udělat.
1. Nasazení trvá dny, ne minuty
Pokud odeslání malé změny vyžaduje vícedenní proces zahrnující více týmů, manuální testování a modlení se — váš deployment pipeline je úzké hrdlo. Moderní týmy nasazují několikrát denně s jistotou. Pokud vy nasazujete týdně (nebo méně), technický dluh vás brzdí.
Řešení: Investujte do automatizace CI/CD, kontejnerizace a automatizovaného testování. Začněte s nejhodnotnější deployment cestou a automatizujte směrem ven.
Má to i druhý, méně viditelný efekt. Když je nasazení drahé, tým začne změny hromadit do velkých balíků — a velké balíky se hůř testují a hůř vrací zpátky. Zrychlení nasazování tak snižuje počet incidentů, i když se na kódu samotném nic nezmění.
2. Nikdo nechce sahat na „ten modul“
Každý legacy systém má alespoň jeden modul, který vývojáře děsí. Je špatně zdokumentovaný, hluboce provázaný se vším ostatním a jakákoliv změna riskuje kaskádové selhání. Když se vývojáři problematickému kódu vyhýbají místo toho, aby ho opravili, složitost narůstá.
Řešení: Aplikujte vzor strangler fig — vybudujte novou funkcionalitu vedle legacy modulu, postupně přesměrujte provoz a nakonec starý kód vyřaďte.
V praxi to vypadá takhle: před starý modul se postaví vrstva, která rozhoduje, kam požadavek pošle. Nejdřív jde všechno postaru. Pak se jedna operace přepne na novou implementaci a sleduje se, jestli dává stejné výsledky. Po několika takových krocích starý modul obsluhuje jen zbytky — a dá se vypnout bez velké noci nasazení.
3. Váš framework již není udržovaný
Provoz na nepodporovaném frameworku není jen problém vývojářského komfortu — je to bezpečnostní riziko. Nezáplatované zranitelnosti ve frameworcích po skončení životnosti jsou aktivně zneužívány. Pokud váš stack zahrnuje PHP 5.x, Python 2.x, Angular.js 1.x nebo Rails 4.x, žijete na dluh.
Řešení: Naplánujte postupnou migraci. Nemusíte přepisovat vše najednou. Začněte s bezpečnostně nejcitlivějšími komponentami a postupujte dál.
K technickému riziku se přidává personální. Na mrtvou verzi frameworku se shání lidé hůř a dráž, a ti, kteří u vás jsou, na ní ztrácejí trh. Náklad se tedy neprojeví jen v incidentech, ale i v náboru — a ten je sám o sobě dražší, než se čeká.
4. Zaškolení trvá měsíce
Pokud noví vývojáři potřebují 3–6 měsíců, aby se stali produktivními, váš kód je příliš složitý. To není problém náboru — to je problém kvality kódu. Nejasná architektura, nekonzistentní vzory a chybějící dokumentace vytvářejí zeď při onboardingu, která se s růstem týmu prohlubuje.
Řešení: Investujte do dokumentace, zaveďte standardy kódování a refaktorujte nejmatoucí oblasti. Každá hodina investovaná do zlepšení vývojářského zážitku se mnohonásobně vrátí.
Dobrý test: dejte novému člověku skutečný úkol a sledujte, kde se zasekne. Ne proto, abyste ho hodnotili — ale protože místa, kde se zasekne, jsou přesně ta, která je potřeba opravit. Ty samé překážky totiž denně zpomalují i ostatní, jen si na ně zvykli.
5. Náklady na infrastrukturu rostou bez odpovídajícího růstu
Pokud váš účet za cloud roste rychleji než vaše uživatelská základna, váš systém je pravděpodobně předimenzovaný kvůli kompenzaci neefektivního kódu. Legacy systémy často plýtvají prostředky — neoptimalizované dotazy, synchronní zpracování tam, kde by stačilo asynchronní, a chybějící vrstvy cache.
Řešení: Profilujte svůj systém, identifikujte nejnákladnější operace a systematicky optimalizujte. Cílený optimalizační sprint může často snížit náklady na infrastrukturu o 30–50%.
Jak taková optimalizace vypadá v detailu včetně čísel, jsme popsali v článku o tom, jak jsme fintech klientovi snížili účet za cloud o 41 %.
Čím začít, když platí víc signálů najednou
Obvykle platí tři ze čtyř a první reakce je chtít všechno naráz. Lepší je seřadit práci podle toho, co blokuje byznys: když se nedá nasazovat, opravuje se nasazování; když padá jedna oblast, zpevní se ta; když nejde sehnat lidi na mrtvou technologii, začíná se migrací.
Před plánem se vyplatí mít mapu: co systém obsahuje, co z toho se opravdu používá a kde jsou rizika. U cizího kódu bez dokumentace to bývá prvních pár týdnů práce — a výstupem je seznam, který se dá ocenit a podle kterého se dá rozhodovat. Takhle vedeme audit kódu; když je potřeba rovnou i stavět, navazuje vývoj systému na míru nebo doplnění vašeho týmu o lidi, kteří se v cizím kódu zorientují sami.
Shrnutí
Modernizace legacy systémů je investice, ne náklad. Společnosti, které proaktivně modernizují své systémy, dodávají rychleji, přitahují lepší talenty a utrácejí méně za infrastrukturu. Ty, které čekají na krizi, zaplatí tři- až pětkrát více — a navíc ztratí pozici na trhu.
Pokud vám některý ze signálů přišel povědomý, nemusíte hned plánovat velký projekt. Stačí si poctivě odpovědět, který z nich vás stojí nejvíc peněz, a začít tam.
Časté otázky
Má smysl přepsat systém od nuly?
Skoro nikdy. Přepis od nuly znamená, že roky nedodáte nic nového, zatímco konkurence pokračuje, a na konci dostanete systém s jinou sadou chyb. Výjimkou je malý systém nebo technologie, pro kterou se nedají sehnat lidé. Ve zbytku případů se vyplatí nahrazovat po částech.
Jak dlouho modernizace trvá?
Záleží na rozsahu, ale první část by měla jít do provozu do pár měsíců. Pokud plán slibuje výsledek až za rok, je špatně nakrájený: smysl postupné modernizace je v tom, že užitek přichází průběžně.
Můžeme modernizovat a zároveň dodávat nové funkce?
Ano, a většinou to tak i musí být — byznys se nezastaví. V praxi to znamená domluvit se na poměru, kolik kapacity jde na nové věci a kolik na úklid, a ten poměr dodržovat i ve chvíli, kdy tlačí termín.
Co když nemáme dokumentaci a původní tým odešel?
To je běžná výchozí situace. Začíná se čtením kódu a měřením toho, co v provozu skutečně běží; z toho vznikne mapa systému. Trvá to týdny, ne měsíce, a je to levnější než hádat.
Jak poznáme, že se modernizace vyplatila?
Metrikami, které jdou změřit před i po: jak dlouho trvá nasazení, kolik incidentů za měsíc, jak dlouho se zaučuje nový člověk, kolik stojí provoz. Když se žádné z těch čísel nehne, peníze šly do něčeho jiného než do výsledku.