Koexistencia legacy-kódu v high-load systémech

Stabilita místo odstranění: strategie pro spolupráci legacy kódu v velkých projektech

V dlouhodobě provozovaných systémech s vysokým zatížením představuje odstranění legacy kódu riziko regresí a ztráty stability. Místo úplného refaktoringu je efektivnější použít strategii spolupráce starého a nového kódu prostřednictvím feature toggles a fasád. Tím lze systém rozvíjet bez výpadků a zároveň zachovat ověřené komponenty jako záložní řešení.

Rizika agresivního odstranění kódu

Odstranění i mrtvého kódu může vyvolat selhání kvůli skrytým závislostem: reflection, dynamické načítání nebo RPC volání. Testy v legacy systémech často nedostatečně pokrývají okrajové případy, zatímco produkční data aktivují vzácné větve logiky. Ztráta institucionální paměti zhoršuje problém – odcházející týmy nechávají kód, který je klíčový pro vzácné scénáře, jako jsou migrace nebo dodržování regulací.

V enterprise prostředích se vlastní moduly dodavatelů stávají citlivé: změny mohou blokovat podporu dodavatele.

Princip "nechte to být" ve praxi

Klasický příklad je NASA s sondou Deep Space 1: kód z roku 1970 zůstal nedotknutý a byl obalen adaptéry. Stabilní komponenty se nijak nemění, pokud plní své úkoly bez problémů. Jedná se o zreálnou strategii pro systémy starší než pět let.

Architektura spolupráce: Strangler Fig v opačném směru

Nedestruktivně zničte legacy — stavte nové řešení paralelně a postupně přesměrujte provoz. Existují dvě hlavní strategie:

| Strategie | Akce | Podmínky použití |

|-----------|------|------------------|

| Odstranění | Přepsat na novém stacku | Jednoduchá logika, 100% pokrytí testy, žádné závislosti |

| Spolupráce | Nový kód paralelně, postupné přesměrování provozu | Kritická funkčnost, slabá testovatelnost, vysoké riziko |

Feature toggles zajišťují bezpečnost:

• Vytvořte novou implementaci.
• Obalte ji kontrolou příznaku.
• Spusťte na 1 % provozu.
• Postupně škálovat při úspěchu.
• Při selhání vrátit zpět pomocí příznaku.

Legacy kód zůstane v repozitáři 2–3 roky pro analýzu spolehlivosti.

Implementace v Spring Boot

Obalte legacy kód do rozhraní, aniž byste měnili původní kód.

// Legacy služba (neměnit)
@Service
public class LegacyDiscountService {
    public double calculateDiscount(Order order) {
        // Logika z minulých 5 let
        return order.getTotal() * 0.1;
    }
}

// Nová služba
@Service
public class NewDiscountService {
    public double calculateDiscount(Order order) {
        return applyComplexRules(order);
    }
}

Fasáda s příznakem:

@Component
public class DiscountServiceFacade {
    private final LegacyDiscountService legacyService;
    private final NewDiscountService newService;
    
    @Value("${feature.discount.new.enabled:false}")
    private boolean useNewService;
    
    public DiscountServiceFacade(LegacyDiscountService legacyService, 
                                 NewDiscountService newService) {
        this.legacyService = legacyService;
        this.newService = newService;
    }
    
    public double calculateDiscount(Order order) {
        if (useNewService) {
            return newService.calculateDiscount(order);
        }
        return legacyService.calculateDiscount(order);
    }
}

Izolace prostřednictvím profilů:

@Configuration
public class DiscountConfiguration {
    
    @Bean
    @ConditionalOnProperty(name = "feature.discount.new", havingValue = "false", matchIfMissing = true)
    public DiscountService legacyDiscountService() {
        return new LegacyDiscountService();
    }
    
    @Bean
    @ConditionalOnProperty(name = "feature.discount.new", havingValue = "true")
    public DiscountService newDiscountService() {
        return new NewDiscountService();
    }
}

Testy vyloučí legacy:

@Test
@DisabledIf("!${feature.discount.new.enabled}")
void testNewDiscountLogic() {
    // Pouze nová logika
}

Schéma přesměrování provozu

API Gateway přesměruje provoz podle příznaků: monolit jako záloha, mikroslužba postupně zvyšuje zatížení. Feature Toggle Service spravuje procenta v reálném čase. Legacy zůstává v produkci 2–3 roky.

Kdy je odstranění nevyhnutelné

• Bezpečnost: CVE v zastaralých knihovnách.
• Kompliance: Porušení GDPR.
• EOL technologií: Java bez aktualizací.
• Chybějící odbornost: Žádní specializovaní pracovníci.

I v těchto případech – postupný rollout s možností vrácení zpět.

Co je důležité

• Stabilita systému převyšuje estetiku kódu: uptime je důležitější než odstranění řádků legacy.
• Skryté závislosti vyžadují monitorování volání v produkci před odstraněním.
• Feature toggles minimalizují rizika při migracích.
• Technický dluh se vyplatí, pokud údržba je levnější než refaktoring.
• Institucionální paměť v kódu: neodstraňujte bez 100% jistoty.

— Editorial Team