Modernizace starého systému, na který si nikdo netroufne sáhnout: přepsat, refaktorovat nebo nahrazovat postupně

Řada firem, které fungují delší dobu, má systém, o kterém se na poradách mluví opatrně. Běží na něm fakturace, sklad nebo výroba, upravovalo ho mnoho lidí, do detailu mu rozumí málokdo a každá změna je pomalá a drahá.

Když se o něm konečně rozhoduje, na stole bývá návrh: přepíšeme to celé od nuly. Zní to lákavě, ale je to riskantní: starý kód je archivem obchodních pravidel, výjimek a oprav nasbíraných za roky, které často nejsou nikde zapsané, a kdo ho zahodí najednou, zahodí i tyto znalosti. Modernizace starého systému má přitom víc podob než „nechat to být“ nebo „přepsat“ a u velkého kritického systému bývá bezpečnější nahrazovat ho po částech za plného provozu.

Symptomy: systém, kterého se firma bojí

Michael Feathers, autor knihy Working Effectively with Legacy Code, definuje legacy kód jednoduše jako kód bez testů. Legacy systém tedy nepoznáte podle stáří, ale podle toho, zda se dá bezpečně měnit. Typické příznaky:

• Jediný člověk, který systému rozumí. Když odejde, firma ztrácí schopnost měnit klíčový proces.
• Strach z nasazování nových verzí. Změny se hromadí do velkých balíků, takže při chybě se hůř dohledává její příčina.
• Zastaralé technologie, na které se těžko shánějí lidé a které výrobce přestal podporovat.
• Bezpečnostní rizika, která nelze odstranit bez zásahu do jádra.
• Nemožnost napojit nové nástroje. Systém nemá API vrstvu, tedy definované rozhraní pro výměnu dat, takže každé propojení s e-shopem nebo AI nástrojem je samostatný projekt.

To všechno jsou podoby technického dluhu, který jako princip celé firmy rozebírá článek Firma je jeden produkt.

Týká se to i státu. Americký kontrolní úřad GAO ve zprávě z července 2025 označil 11 nejkritičtějších federálních systémů, které potřebují modernizaci. Osm z nich používá zastaralé jazyky jako COBOL a assembler a sedm podle agentur běží se známými zranitelnostmi, které bez modernizace nelze odstranit.

Proč je „přepíšeme to celé od nuly“ tak lákavé

Big bang rewrite znamená postavit nový systém od nuly a najednou na něj přepnout celou firmu. Slibuje nový začátek s čistým štítem a moderní technologii. Joel Spolsky v eseji z roku 2000 přidává méně lichotivý důvod: programátoři považují starý kód za nepořádek hlavně proto, že číst kód je těžší než ho psát. Přepsání kódu od nuly označil za nejhorší strategickou chybu, jakou může softwarová firma udělat. Jako příklad uvedl Netscape: první veřejná beta verze 6.0 vyšla téměř tři roky po verzi 4.0 a tržní podíl firmy mezitím prudce klesal.

Je to vyhraněný názor, konkrétní mechanismy selhání se ale dají pojmenovat:

• Skrytá pravidla. Neúhledné části starého kódu jsou podle Spolského často opravy chyb, které se projevily až po týdnech reálného používání. Přepis je zahodí a tytéž chyby se mohou objevit znovu, opět až v ostrém provozu.
• Dvojí vývoj. Běžné požadavky z byznysu se podle autorů z Thoughtworks dál řeší ve starém systému, takže firma platí dva vývojové proudy najednou.
• Dlouhé období bez přínosu. Martin Fowler připomíná, že náhrada významného IT systému trvá dlouho a uživatelé nemohou na nové funkce čekat.
• Pohyblivý cíl. Autoři z Thoughtworks popisují organizaci, v níž se vystřídala řada tříletých až pětiletých modernizačních programů. V každém z nich měnící se potřeby byznysu předběhly technologickou strategii a začínalo se znovu. Tam, kde program běžel jako big bang, to znamenalo zahodit většinu práce.

Šest možností a kdy se která hodí

1. Ponechat a stabilizovat. Doplnit sledování chyb a výpadků, zálohy a dokumentaci, zaučit do systému druhého člověka. Hodí se, když systém svou práci dělá a mění se zřídka. Bývá to nejlevnější způsob, jak snížit riziko.
2. Refaktorovat. Refaktoring je podle Martina Fowlera změna vnitřní struktury softwaru, díky které je srozumitelnější a jeho úpravy jsou levnější, aniž se změní jeho pozorovatelné chování. Hodí se, když je technologie v pořádku, ale kód je spletitý.
3. Přesunout na novou infrastrukturu, například z vlastního serveru do cloudu. Hodí se, když potíže způsobuje provoz nebo hardware. Špatnou logiku aplikace přesun nevyléčí.
4. Postupně nahrazovat. Hodí se u velkých kritických systémů, které nelze odstavit, jejichž chování nikdo nezná celé a které mohou ještě dlouho běžet souběžně s novými.
5. Koupit hotové řešení. U standardního procesu, jako je účetnictví nebo docházka, bývá vlastní vývoj zbytečný, proces se však musí přizpůsobit produktu. Tuto volbu rozebírá článek Sedm SaaS nástrojů nebo jeden systém?
6. Zrušit. Pokud systém obsluhuje proces, který zanikl, je ještě třeba ověřit, zda z něj nečerpají data jiné systémy nebo reporty.

Strangler fig: nový systém roste vedle starého

Název strangler fig pattern vychází z metafory Martina Fowlera: v roce 2001 viděl v pralesích Queenslandu škrtící fíkovníky, které postupně obrostou hostitelský strom, až ho nahradí. Nový systém podobně nevzniká místo starého, ale vedle něj. Přebírá funkce jednu po druhé, dokud nebude možné starý systém vypnout.

Dokumentace Microsoftu popisuje mechanismus: mezi uživatele a oba systémy se vloží fasáda, tedy prostředník, který požadavky postupně přesměrovává ze starého systému do nového, například nejprve jen výpočet cenových nabídek. Uživatelé o migraci nevědí. Starý systém podle Featherse zůstává jako záloha pro případ problémů.

Fowler přiznává i cenu tohoto přístupu: přechodnou architekturu pro souběžný chod obou systémů, která po dokončení zanikne. Nižší riziko a dřívější přínos ji podle něj převáží, protože vyměňované části jsou malé. Varuje však, že bez změny kultury a vedení skončí i nový systém v podobném nepořádku.

Data jsou nejtěžší část

Kód lze vyměňovat po kouscích, data ale během přechodu potřebují oba systémy současně. Migrace dat, tedy přesun údajů ze staré struktury do nové, není obyčejné kopírování. Výzkumníci z Trinity College Dublin upozorňují, že data ze starých systémů bývají nekvalitní, je třeba je namapovat na novou strukturu a často také vyčistit. V praxi jde například o duplicitní záznamy, pole používaná k jinému účelu a hodnoty, kterým rozumí jen starý kód.

Microsoft doporučuje oddělovat data postupně, po jednotlivých oblastech: novou databázi naplnit úvodním přenosem, další změny přenášet technikou change data capture, tedy zachytáváním změn ve staré databázi, před přepnutím ověřit shodu a staré objekty odstranit až po validaci nového systému. Do té doby je návrat možný, potom je výrazně náročnější a rizikovější.

Pro každý typ údajů musí být během přechodu jasné, který systém je jediným zdrojem pravdy. Pokud lze adresu zákazníka změnit v obou systémech, hrozí, že každý bude mít jinou. Náš praktický závěr: každý konkrétní údaj ať lidé mění vždy jen v jednom systému a ostatní systémy ho z něj pouze přebírají. Širší roli dat se věnuje článek Vaše data jsou náskok.

Jak zjistit, co systém skutečně dělá

Feathers upozorňuje, že lidé nosí v hlavě představu o tom, co systém dělá, a zapomínají se podívat, co dělá ve skutečnosti. Pomáhají tři zdroje:

• Pozorování uživatelů. Sledovat, co lidé se systémem dělají, ne co o tom říkají. Tady se ukážou obezličky, tabulky vedené bokem a ruční kroky.
• Logy, tedy záznamy o činnosti systému. Ukážou, které funkce se používají, jak často a kým, a pomohou odhalit nečekané závislosti.
• Testy současného chování. Feathers popisuje charakterizační testy: kódu se položí otázka a zjištěná odpověď se zapíše jako očekávaný výsledek. Vznikají tak regresní testy, tedy automatické kontroly, které po každé změně ověří, že to, co fungovalo, funguje dál.

Autoři z Thoughtworks popisují tým, který v ostrém provozu testoval náhradu integračního middlewaru, tedy softwaru propojujícího ostatní systémy. Krátce nato přestaly sedět kritické manažerské reporty. Po dlouhém pátrání se ukázalo, že se databáze middlewaru replikovala do datového skladu, ze kterého reporty čerpaly. Pomohl až dočasný mechanismus, který do skladu doplňoval chybějící údaje.

Pořadí: největší bolest, nejmenší riziko

Migrace by neměla být prvním krokem. I tady používáme pořadí Remove, Simplify, Automate, Augment: nejprve odstranit, pak zjednodušit a teprve potom automatizovat a rozšiřovat. Autoři z Thoughtworks upozorňují, že většina starých systémů časem nabobtná funkcemi, které nikdo nepoužívá, a odvolávají se na zprávu Standish Group z roku 2014, podle které jde o 50 % funkcí. Pro konkrétní systém je to jen orientační údaj, skutečnost ukážou logy. Zrušenou funkci není třeba analyzovat, migrovat ani testovat a obezličky, které obcházejí omezení starého systému, se při přenosu vyplatí zjednodušit, ne kopírovat.

První nahrazovaná část by měla firmu citelně bolet, například brzdit obchod, a zároveň být relativně oddělená od jádra. Feathers radí soustředit se na části, které porostou a zároveň dělají potíže, a pro odklonění požadavků najít švy, jak nazývá místa, kde lze jedno chování nahradit jiným.

Rizika a jak je měřit během přechodu

Postupná náhrada riziko neodstraňuje, rozděluje ho na menší a měřitelné části. Opačný přístup ilustruje rozhodnutí britského regulátora FCA z 20. 12. 2022. Banka TSB o víkendu 20. až 22. dubna 2018 přesunula většinu provozu a zákaznických dat na novou, dosud neověřenou platformu. Následovaly vážné problémy s internetovým a mobilním bankovnictvím i s platbami kartou a do 7. dubna 2019 banka obdržela 225 492 stížností. FCA konstatovala selhání v plánování, testování, řízení rizik i v dohledu nad externím dodavatelem, upozornila, že po spuštění se banka prakticky nemohla vrátit na původní platformu, a uložila pokutu 29,75 mil. GBP.

Bezpečnější cestu popsal Vicent Martí z GitHubu v roce 2015. Tým nahrazoval jednu z nejkritičtějších částí kódu přímo v ostrém provozu: starý i nový kód běžely souběžně, výsledky se porovnávaly a uživatel vždy dostal výsledek starého kódu. Experiment začal na 1 % požadavků a postupně se rozšiřoval, až 24 hodin běžel na 100 % požadavků bez neshod. Porovnávání navíc odhalilo 2 vážné chyby v původním řešení, kterých si roky nikdo nevšiml.

Co tedy sledovat:

• Shodu výsledků starého a nového řešení na reálných datech před přepnutím.
• Chybovost a výkon po každém přesměrování.
• Cestu zpět: jak rychle se firma vrátí k původnímu stavu.
• Konzistenci dat a počet ručních oprav.
• Podíl převzatého provozu. Pokud dlouhodobě neroste, stává se z projektu dvojí provoz bez konce.

Kdy je úplné přepsání opodstatněné

Úplné přepsání není vždy chyba. Feathers ho popisuje jako obchodní rozhodnutí, které se řídí návratností, sám ale nejprve zkouší refaktoring a připomíná, že celý systém většinou přepisovat není nutné a cílené přepisy jednotlivých částí bývají velmi účinné. Microsoft uvádí, kdy postupná náhrada vhodná není: systém je malý a dá se snadno nahradit celý, ke zdrojovému kódu není přístup nebo je třeba původní řešení rychle vyřadit. Autoři z Thoughtworks připouštějí věrnou kopii starých funkcí u systémů s dobře známou specifikací, kde daný vstup musí dát daný výstup, takové případy však považují za výjimečné.

Náš názor: přepis je obhajitelný i tehdy, když se byznys změnil natolik, že starý systém podporuje způsob práce, který firma opouští. Pak ale jde o nový produkt s novým zadáním, ne o kopii starých funkcí.

Modernizace starého systému proto nezačíná výběrem technologie, ale pochopením, jakou práci systém pro firmu dělá, které jeho části se skutečně používají a kde přesně vzniká bolest. Kdo tuto diagnózu přeskočí, vybírá mezi přepisem a refaktoringem naslepo.

Co si z toho vzít

• Nevybíráte jen mezi „nechat“ a „přepsat“, ale ze šesti možností. Stabilizace, hotové řešení nebo zrušení bývají levnější než přepis.
• Před migrací zjistěte, co systém skutečně dělá: pozorováním lidí, z logů a testy současného chování.
• Nejprve odstraňte nepoužívané funkce, jinak je budete zbytečně migrovat a testovat.
• Velký kritický systém nahrazujte po částech, začněte tam, kde je největší bolest a nejmenší riziko, a mějte připravenou cestu zpět.
• Pro každý typ dat určete jediný zdroj pravdy a měřte shodu výsledků, chybovost a podíl převzatého provozu.