Legacy ve vývoji aplikací — co to je, rizika a strategie práce

Co je legacy ve vývoji aplikací

Legacy — kód nebo systém, který nadále funguje v produkci, ale již nesplňuje moderní standardy kvality. Legacy může být napsáno v zastaralém jazyce (např. Objective-C místo Swift), používat nepodporované knihovny nebo architektonické vzory, které jsou dávno považovány za antivzory.

Klíčovou vlastností legacy je nedostatek testů. Podle definice Michaela Featherse (2004) je legacy kód kód bez testů. Pokud nelze chování bezpečně změnit, systém je ve statusu legacy bez ohledu na stáří. Čerstvý kód bez unit testů — to je legacy prvního dne.

Legacy není nutně špatné. Dobře navržený systém v Java 8 může být spolehlivější a srozumitelnější než chaotický kód v Kotlinu s korutinami. Stáří kódu není ukazatelem kvality — důležité je, jak snadno systém podléhá změnám a rozšiřování.

Proč je legacy kód normální

Každý úspěšný systém se časem stává legacy. To je přirozený proces: technologie se vyvíjejí rychleji, než může být kód přepsán. Aplikace napsaná před 5 lety ve Swift 2 je dnes legacy, i když v okamžiku vzniku byla moderní.

Obchodní hodnota legacy je často podceňována. Systém stabilně funguje, zpracovává transakce, ukládá data — přepisování přináší rizika. Podle Standish Group (2024) 35% projektů úplného přepsání končí neúspěchem. Ekonomicky není zbavení se legacy ospravedlnitelné, ale naučit se s ním pracovat.

Nejlepší strategie — postupná migrace, zapouzdření starého kódu za nová rozhraní a automatizované testování. Legacy se stává problémem pouze tehdy, když přestane podléhat změnám s předvídatelnými náklady.

Hlavní znaky legacy systému

Nedostatek automatických testů — hlavní indikátor. Pokud po změně jednoho řádku kódu programátor nemůže spustit testy a ujistit se, že se nic nerozbilo — máte co do činění s legacy. Další znak: postup nasazení trvá hodiny a vyžaduje ruční zásahy.

Dokumentace neodpovídá kódu — další marker. Architektonické diagramy jsou zastaralé, komentáře popisují chování, které se již změnilo. Time-to-ramp-up pro nového programátora přesahuje měsíc — znak vysoké složitosti a nízké udržovatelnosti systému.

Další znaky: monolitická architektura bez jasných hranic, ruční testování jako hlavní metoda ověřování, dlouhý CI pipeline (více než 30 minut), používání knihoven bez aktuálních verzí a nemožnost aktualizovat závislosti bez rozbití sousedních modulů.

Fenomén „křehkého kódu” — změna na jednom místě rozbije tři další. To je důsledek těsného provázání (tight coupling), kdy moduly o sobě vědí příliš mnoho. Čím vyšší je coupling, tím rychleji systém přechází do kategorie legacy.

Rizika práce se zastaralým kódem

Snižení rychlosti — hlavní riziko. Přidání jednoduché funkce vyžaduje hodiny studia kódu a dny testování. Podle Stripe (2024) tráví programátoři 33% času překonáváním technického dluhu, který přímo souvisí s přítomností legacy modulů v projektu.

Únik expertízy — autoři původního kódu odcházejí ze společnosti a dokumentace je neúplná. Noví programátoři se bojí dotýkat nepochopitelných modulů, což vede k efektu „zmrzlého kódu”: modul se nevyvíjí, ale nadále funguje. Bus factor takových systémů je kriticky nízký.

Bezpečnost — zastaralé knihovny obsahují známé zranitelnosti. Používání OpenSSL 1.0.2 nebo zastaralých verzí Jacksonu v Java projektech je přímou cestou k bezpečnostním incidentům, které mohou firmu stát reputaci a zákazníky.

Demotivace týmu — práce s legacy bez strategie jeho zlepšování snižuje spokojenost programátorů. Tým přestává být hrdý na produkt, fluktuace roste, což dále zpomaluje vývoj systému.

Strategie refaktoringu legacy

Charakterizační testy — první krok před jakoukoli změnou legacy kódu. Spusť kód na známých vstupních datech a zaznamenej očekávaný výstup. Tyto testy zachycují aktuální chování jako specifikaci. Golden master testing — varianta, kdy se výstupní data porovnávají s referenčním souborem.

Seam analýza — hledání bodů, kde lze přerušit provázání bez změny chování. Michael Feathers rozlišuje několik typů seam: preprocessor seam, object seam, link seam. Object seam — nejběžnější: nahrazení skutečného objektu testovacím stubem přes rozhraní.

Sprout method a Sprout class — techniky přidávání nového kódu vedle starého, ne uvnitř něj. Místo úpravy existující metody vytvoř novou metodu s potřebnou logikou a volej ji ze staré. Tím se minimalizuje riziko rozbití fungujícího kódu.

Příklad: přidání logování v legacy

class LegacyPaymentProcessor {
    def process(payment) {
        // 200 řádků legacy kódu, kterých by se nemělo dotýkat
        logPayment(payment) // sprout method
    }
    def logPayment(payment) {
        // nový kód přidaný vedle legacy
    }
}

Migrace na moderní technologický stack

Vzor Strangler Fig — doporučený přístup pro migraci legacy. Nový modul je vytvářen paralelně, provoz je postupně přepínán ze starého na nový. Starý modul přirozeně „umírá”, když přestane dostávat požadavky. Vzor minimalizuje rizika a umožňuje návrat v případě problémů.

Branch by Abstraction — technika, při které se vytváří abstrakce nad starou a novou implementací. Klientský kód přechází na abstrakci, stará implementace je postupně nahrazována novou. Příklad: nahrazení síťové vrstvy z AFNetworking na Alamofire přes jednotný protokol NetworkService.

Postupná migrace — rozdělení přechodu na malé kroky: zapouzdření starého modulu → psaní testů → vytvoření nového modulu → paralelní spuštění → odstranění starého modulu. Každý krok končí stabilním stavem systému, což umožňuje nasazení změn kdykoli.