Starý systém, na ktorý sa nikto neodváži siahnuť: prepísať, refaktorovať alebo nahrádzať postupne

Mnohé firmy, ktoré fungujú dlhšie, majú systém, o ktorom sa na poradách hovorí opatrne. Beží na ňom fakturácia, sklad alebo výroba, upravovalo ho veľa ľudí, do detailu mu rozumie málokto a každá zmena je pomalá a drahá.

Keď sa o ňom konečne rozhoduje, na stole býva veta: prepíšeme to celé nanovo. Znie to lákavo, ale je to riskantné: starý kód je archív obchodných pravidiel, výnimiek a opráv nazbieraných za roky, ktoré často nikto nemá zapísané, a kto ho zahodí naraz, zahodí aj toto poznanie. Modernizácia starého systému má pritom viac podôb než „nechať tak“ alebo „prepísať“ a pri veľkom kritickom systéme býva bezpečnejšie nahrádzať ho po častiach za plnej prevádzky.

Symptómy: systém, ktorého sa firma bojí

Michael Feathers, autor knihy Working Effectively with Legacy Code, definuje legacy kód jednoducho ako kód bez testov. Legacy systém teda nespoznáte podľa veku, ale podľa toho, či sa dá bezpečne meniť. Typické príznaky:

• Jediný človek, ktorý systému rozumie. Keď odíde, firma stráca schopnosť meniť kľúčový proces.
• Strach z nasadení. Zmeny sa hromadia do veľkých balíkov, takže pri chybe sa ťažšie hľadá jej príčina.
• Zastarané technológie, pre ktoré sa ťažko hľadajú ľudia a ktoré výrobca prestal podporovať.
• Bezpečnostné riziká, ktoré sa nedajú odstrániť bez zásahu do jadra.
• Nemožnosť napojiť nové nástroje. Systém nemá API vrstvu, teda definované rozhranie na výmenu dát, takže každé prepojenie s e-shopom alebo AI nástrojom je samostatný projekt.

Všetko sú to podoby technického dlhu, ktorý ako princíp celej firmy rozoberá článok Firma je jeden produkt.

Týka sa to aj štátu. Americký kontrolný úrad GAO v správe z júla 2025 označil 11 najkritickejších federálnych systémov, ktoré potrebujú modernizáciu. Osem z nich používa zastarané jazyky ako COBOL a assembler a sedem podľa agentúr beží so známymi zraniteľnosťami, ktoré sa bez modernizácie nedajú odstrániť.

Prečo je „prepíšeme to celé nanovo“ také lákavé

Big bang rewrite znamená postaviť nový systém od nuly a naraz naň prepnúť celú firmu. Sľubuje čistý štart a modernú technológiu. Joel Spolsky v eseji z roku 2000 pridáva menej lichotivý dôvod: programátori pokladajú starý kód za neporiadok najmä preto, že čítať kód je ťažšie ako ho písať. Prepísanie kódu od nuly označil za najhoršiu strategickú chybu, akú môže softvérová firma urobiť. Ako príklad uviedol Netscape: verzia 6.0 išla do prvej verejnej bety takmer tri roky po verzii 4.0 a trhový podiel firmy medzitým prudko klesal.

Je to vyhranený názor, konkrétne mechanizmy zlyhania sa však dajú pomenovať:

• Skryté pravidlá. Nepekné časti starého kódu sú podľa Spolskyho často opravy chýb, ktoré sa prejavili až po týždňoch reálneho používania. Prepis ich zahodí a tie isté chyby sa môžu objaviť znova, opäť až v ostrej prevádzke.
• Dvojitý vývoj. Bežné požiadavky biznisu sa podľa autorov z Thoughtworks ďalej riešia v starom systéme, takže firma platí dva vývojové prúdy naraz.
• Dlhé obdobie bez hodnoty. Martin Fowler pripomína, že náhrada vážneho IT systému trvá dlho a používatelia nemôžu na nové funkcie čakať.
• Posúvajúci sa cieľ. Autori z Thoughtworks opisujú organizáciu so sériou trojročných až päťročných modernizačných programov. V každom z nich meniace sa potreby biznisu predbehli technologickú stratégiu a začínalo sa odznova. Kde program bežal ako big bang, znamenalo to zahodiť väčšinu práce.

Šesť možností a kedy ktorá sedí

1. Ponechať a stabilizovať. Doplniť sledovanie chýb a výpadkov, zálohy a dokumentáciu, zaučiť druhého človeka, ktorý systému rozumie. Sedí, keď systém svoju prácu robí a mení sa zriedka. Býva to najlacnejší spôsob, ako znížiť riziko.
2. Refaktorovať. Refaktoring je podľa Martina Fowlera zmena vnútornej štruktúry softvéru, ktorá ho robí zrozumiteľnejším a lacnejšie upraviteľným bez zmeny jeho pozorovateľného správania. Sedí, keď je technológia v poriadku, ale kód je spletitý.
3. Presunúť na novú infraštruktúru, napríklad z vlastného servera do cloudu. Sedí, keď bolí prevádzka alebo hardvér. Zlú logiku aplikácie presun nevylieči.
4. Postupne nahrádzať. Sedí pri veľkých kritických systémoch, ktoré nemôžu stáť, ktorých správanie nikto nepozná celé a ktoré môžu ešte dlho bežať súbežne s novými.
5. Kúpiť hotové riešenie. Pri štandardnom procese, ako je účtovníctvo alebo dochádzka, býva vlastný vývoj zbytočný, proces sa však musí prispôsobiť produktu. Túto voľbu rozoberá článok Sedem SaaS nástrojov alebo jeden systém?
6. Zrušiť. Ak systém obsluhuje proces, ktorý zanikol, treba ešte overiť, či z neho nečerpajú dáta iné systémy alebo reporty.

Strangler fig: nový systém rastie vedľa starého

Názov strangler fig pattern vychádza z metafory Martina Fowlera: v roku 2001 videl v pralesoch Queenslandu škrtiace figovníky, ktoré postupne obrastú hostiteľský strom, až ho nahradia. Nový systém podobne nevzniká namiesto starého, ale vedľa neho. Preberá funkcie jednu po druhej, kým sa starý nedá vypnúť.

Dokumentácia Microsoftu opisuje mechanizmus: medzi používateľov a oba systémy sa vloží fasáda, teda prostredník, ktorý požiadavky postupne presúva zo starého systému do nového, napríklad najprv iba výpočet cenových ponúk. Používatelia o migrácii nevedia. Starý systém podľa Feathersa zostáva ako záloha pre prípad problémov.

Fowler priznáva cenu: prechodnú architektúru pre súbežný chod oboch systémov, ktorá po dokončení zanikne. Nižšie riziko a skoršia hodnota ju podľa neho prevážia, lebo vymieňané časti sú malé. Varuje však, že bez zmeny kultúry a vedenia skončí aj nový systém v podobnom neporiadku.

Dáta sú najťažšia časť

Kód sa dá vymieňať po kúskoch, dáta však počas prechodu potrebujú oba systémy naraz. Migrácia dát, teda presun údajov zo starej štruktúry do novej, nie je obyčajné kopírovanie. Výskumníci z Trinity College Dublin upozorňujú, že dáta zo starých systémov bývajú nekvalitné, treba ich namapovať na novú štruktúru a často aj vyčistiť. V praxi ide napríklad o duplicity, polia používané na iný účel a hodnoty, ktorým rozumie iba starý kód.

Microsoft odporúča oddeľovať dáta postupne, po oblastiach: novú databázu naplniť úvodným prenosom, ďalšie zmeny prenášať technikou change data capture, teda zachytávaním zmien v starej databáze, pred prepnutím overiť zhodu a staré objekty odstrániť až po validácii nového systému. Dovtedy je návrat možný, potom je výrazne náročnejší a rizikovejší.

Pre každý typ údajov musí byť počas prechodu jasné, ktorý systém je jediný zdroj pravdy. Ak sa adresa zákazníka dá zmeniť v oboch systémoch, hrozí, že každý bude mať inú. Náš praktický záver: konkrétne údaje nech ľudia menia vždy iba v jednom systéme a ostatné systémy ich z neho len preberajú. Širšej úlohe dát sa venuje článok Vaše dáta sú náskok.

Ako zistiť, čo systém naozaj robí

Feathers upozorňuje, že ľudia nosia v hlave predstavu o tom, čo systém robí, a zabúdajú sa pozrieť, čo robí v skutočnosti. Pomáhajú tri zdroje:

• Pozorovanie používateľov. Sledovať, čo ľudia so systémom robia, nie čo o tom hovoria. Tu sa ukážu obchádzky, tabuľky bokom a ručné kroky.
• Logy, teda záznamy o činnosti systému. Ukážu, ktoré funkcie sa používajú, ako často a kým, a pomôžu odhaliť nečakané závislosti.
• Testy súčasného správania. Feathers opisuje charakterizačné testy: kódu sa položí otázka a zistená odpoveď sa zapíše ako očakávaný výsledok. Vznikajú tak regresné testy, teda automatické kontroly, ktoré po každej zmene overia, že to, čo fungovalo, funguje ďalej.

Autori z Thoughtworks opisujú tím, ktorý v ostrej prevádzke testoval náhradu integračného middleware, teda softvéru prepájajúceho ostatné systémy. Krátko nato prestali sedieť kritické manažérske reporty. Po dlhom pátraní sa ukázalo, že databáza middleware sa replikovala do dátového skladu, z ktorého reporty čerpali. Pomohol až dočasný mechanizmus, ktorý do skladu dopĺňal chýbajúce údaje.

Poradie: najväčšia bolesť, najmenšie riziko

Migrácia nemá byť prvým krokom. Aj tu používame poradie Remove, Simplify, Automate, Augment: najprv odstrániť, potom zjednodušiť, až potom automatizovať a rozširovať. Autori z Thoughtworks upozorňujú, že väčšina starých systémov sa časom nafúkne o funkcie, ktoré nikto nepoužíva, a odvolávajú sa na správu Standish Group z roku 2014, podľa ktorej ide o 50 % funkcií. Pre konkrétny systém je to iba orientačný údaj, skutočnosť ukážu logy. Zrušenú funkciu netreba analyzovať, migrovať ani testovať a obchádzky obmedzení starého systému sa pri prenose oplatí zjednodušiť, nie kopírovať.

Prvá nahrádzaná časť má spôsobovať citeľnú bolesť, napríklad brzdiť obchod, a zároveň byť relatívne oddelená od jadra. Feathers radí sústrediť sa na časti, ktoré budú rásť a zároveň robia ťažkosti, a na odklonenie požiadaviek nájsť švy, ako nazýva miesta, kde sa dá jedno správanie nahradiť iným.

Riziká a ako ich merať počas prechodu

Postupná náhrada riziko neodstraňuje, delí ho na menšie a merateľné kusy. Opak ilustruje rozhodnutie britského regulátora FCA z 20. 12. 2022. Banka TSB cez víkend 20. až 22. apríla 2018 presunula väčšinu prevádzky a zákazníckych dát na novú, ešte neoverenú platformu. Nasledovali vážne problémy s internetovým a mobilným bankovníctvom aj s platbami kartou a do 7. apríla 2019 dostala banka 225 492 sťažností. FCA konštatovala zlyhania v plánovaní, testovaní, riadení rizík aj v dohľade nad externým dodávateľom, upozornila, že po spustení sa banka prakticky nemohla vrátiť na pôvodnú platformu, a uložila pokutu 29,75 mil. GBP.

Bezpečnejšiu cestu opísal Vicent Martí z GitHubu v roku 2015. Tím nahrádzal jednu z najkritickejších častí kódu priamo v ostrej prevádzke: starý aj nový kód bežali súbežne, výsledky sa porovnávali a používateľ vždy dostal výsledok starého. Experiment začal na 1 % požiadaviek a postupne sa rozšíril, až 24 hodín bežal na 100 % bez nezhôd. Porovnávanie navyše odhalilo 2 vážne chyby v pôvodnom riešení, ktoré roky nikto nezistil.

Čo teda sledovať:

• Zhodu výsledkov starého a nového riešenia na reálnych dátach pred prepnutím.
• Chybovosť a výkon po každom presmerovaní.
• Cestu späť: ako rýchlo sa firma vráti k pôvodnému stavu.
• Konzistenciu dát a počet ručných opráv.
• Podiel prevzatej prevádzky. Ak dlhodobo nerastie, projekt sa mení na dvojitú prevádzku bez konca.

Kedy je úplné prepísanie oprávnené

Úplné prepísanie nie je vždy chyba. Feathers ho opisuje ako biznisové rozhodnutie o návratnosti, sám však najprv skúša refaktoring a pripomína, že celý systém väčšinou prepisovať netreba a cielené prepisy jednotlivých častí bývajú veľmi účinné. Microsoft uvádza, kedy postupná náhrada nie je vhodná: systém je malý a dá sa jednoducho nahradiť celý, k zdrojovému kódu nie je prístup alebo treba pôvodné riešenie vyradiť rýchlo. Autori z Thoughtworks pripúšťajú verné zopakovanie starých funkcií pri systémoch s dobre známou špecifikáciou, kde daný vstup musí dať daný výstup, také prípady však považujú za výnimočné.

Náš názor: prepis je obhájiteľný aj vtedy, keď sa biznis zmenil natoľko, že starý systém podporuje spôsob práce, ktorý firma opúšťa. Vtedy však ide o nový produkt s novým zadaním, nie o kópiu starých funkcií.

Modernizácia starého systému preto nezačína výberom technológie, ale pochopením, akú prácu systém pre firmu robí, ktoré jeho časti sa naozaj používajú a kde presne vzniká bolesť. Kto túto diagnózu preskočí, vyberá medzi prepisom a refaktoringom naslepo.

Čo si z toho zobrať

• Nevyberáte iba medzi „nechať“ a „prepísať“, ale zo šiestich možností. Stabilizácia, hotové riešenie alebo zrušenie bývajú lacnejšie než prepis.
• Pred migráciou zistite, čo systém naozaj robí: pozorovaním ľudí, z logov a testami súčasného správania.
• Najprv odstráňte nepoužívané funkcie, inak ich budete zbytočne migrovať a testovať.
• Veľký kritický systém nahrádzajte po častiach, začnite tam, kde je najväčšia bolesť a najmenšie riziko, a majte cestu späť.
• Pre každý typ dát určite jediný zdroj pravdy a merajte zhodu výsledkov, chybovosť a podiel prevzatej prevádzky.