Legacy az alkalmazásfejlesztésben — mi ez, kockázatok és munkastratégiák

Mi a legacy az alkalmazásfejlesztésben

Legacy — kód vagy rendszer, amely továbbra is élesben működik, de már nem felel meg a modern minőségi szabványoknak. A legacy lehet elavult nyelven írva (pl. Objective-C a Swift helyett), nem támogatott könyvtárakat vagy olyan architekturális mintákat használ, amelyeket régóta antimintáknak tekintenek.

A legacy legfőbb jellemzője a tesztek hiánya. Michael Feathers (2004) meghatározása szerint a legacy kód kód tesztek nélkül. Ha a viselkedés nem változtatható meg biztonságosan, a rendszer korától függetlenül legacy státuszban van. Friss kód egységtesztek nélkül — az első naptól legacy.

A legacy nem feltétlenül rossz. Egy jól megtervezett Java 8 rendszer megbízhatóbb és érthetőbb lehet, mint egy kaotikus Kotlin kód coroutine-okkal. A kód kora nem minőségi mutató — az a fontos, mennyire alkalmas a rendszer változtatásokra és bővítésre.

Miért normális a legacy kód

Minden sikeres rendszer idővel legacy-vé válik. Ez természetes folyamat: a technológiák gyorsabban fejlődnek, mint ahogy a kód újraírható. Az 5 éve Swift 2-ben írt alkalmazás ma legacy, bár a létrehozásakor modern volt.

A legacy üzleti értékét gyakran alábecsülik. A rendszer stabilan működik, tranzakciókat dolgoz fel, adatokat tárol — az újraírás kockázatokkal jár. A Standish Group (2024) szerint a teljes újraírási projektek 35%-a kudarccal végződik. Gazdaságilag nem a legacy-től való megszabadulás indokolt, hanem a vele való munkamegtanulás.

A legjobb stratégiák — fokozatos migráció, a régi kód új interfészek mögé való elrejtése és automatizált tesztelés. A legacy csak akkor válik problémává, amikor már nem változtatható kiszámítható költséggel.

A legacy rendszer fő jelei

Automatizált tesztek hiánya — a fő mutató. Ha egy kódsor megváltoztatása után a fejlesztő nem tudja futtatni a teszteket és meggyőződni arról, hogy semmi nem romlott el — legacy-val van dolga. További jel: a telepítési eljárás órákig tart és manuális műveleteket igényel.

A dokumentáció nem egyezik a kóddal — egy másik jelző. Az architekturális diagramok elavultak, a kommentek olyan viselkedést írnak le, amely már megváltozott. Time-to-ramp-up egy új fejlesztő számára meghaladja az egy hónapot — a rendszer magas komplexitásának és alacsony karbantarthatóságának jele.

További jelek: monolitikus architektúra egyértelmű határok nélkül, manuális tesztelés mint fő ellenőrzési módszer, hosszú CI pipeline (több mint 30 perc), aktuális verzió nélküli könyvtárak használata és a függőségek frissítésének képtelensége a szomszédos modulok törése nélkül.

„Törékeny kód” jelenség — egy helyen történő változtatás három másikat tönkretesz. Ez a szoros kapcsolódás (tight coupling) következménye, amikor a modulok túl sokat tudnak egymásról. Minél magasabb a coupling, annál gyorsabban kerül át a rendszer a legacy kategóriába.

Az elavult kóddal való munka kockázatai

Sebesség csökkenése — a fő kockázat. Egy egyszerű funkció hozzáadása a kód tanulmányozásához órákat, a teszteléshez napokat igényel. A Stripe (2024) szerint a fejlesztők idejük 33%-át technikai adósság leküzdésére fordítják, amely közvetlenül kapcsolódik a legacy modulok jelenlétéhez a projektben.

Szakértelem elvesztése — az eredeti kód szerzői elhagyják a céget, a dokumentáció pedig hiányos. Az új fejlesztők félnek hozzányúlni az érthetetlen modulokhoz, ami a „befagyott kód” hatásához vezet: a modul nem fejlődik, de tovább működik. Az ilyen rendszerek Bus faktora kritikusan alacsony.

Biztonság — az elavult könyvtárak ismert sebezhetőségeket tartalmaznak. Az OpenSSL 1.0.2 vagy a Jackson elavult verzióinak használata Java projektekben közvetlen út a biztonsági incidensekhez, amelyek a vállalkozást a hírnévbe és ügyfelekbe kerülhetnek.

Csapat demotiválódása — a legacy-vel való munka javítási stratégia nélkül csökkenti a fejlesztők elégedettségét. A csapat már nem büszke a termékre, a fluktuáció nő, ami tovább lassítja a rendszer fejlődését.

Legacy refaktorálási stratégiák

Jellemző tesztek — az első lépés bármilyen legacy kód változtatás előtt. Futtasd a kódot ismert bemeneti adatokon és rögzítsd a várt kimenetet. Ezek a tesztek specifikációként rögzítik a jelenlegi viselkedést. Golden master testing — variáns, ahol a kimeneti adatokat egy referenciához hasonlítják.

Seam analízis – olyan pontok keresése, ahol a kapcsolódás megszakítható a viselkedés megváltoztatása nélkül. Michael Feathers több seam típust különböztet meg: preprocessor seam, object seam, link seam. Object seam — a leggyakoribb: valós objektum lecserélése teszt-stubra egy interfészen keresztül.

Sprout method és Sprout class — technikák új kód hozzáadására a régi mellett, nem pedig benne. A meglévő metódus módosítása helyett hozz létre egy új metódust a szükséges logikával és hívd meg a régiből. Ez minimalizálja a működő kód eltörésének kockázatát.

Példa: naplózás hozzáadása legacy-ben

class LegacyPaymentProcessor {
    def process(payment) {
        // 200 sor legacy kód, amihez nem szabad nyúlni
        logPayment(payment) // sprout method
    }
    def logPayment(payment) {
        // új kód hozzáadva a legacy mellé
    }
}

Migráció modern technológiai stackre

Strangler Fig minta — ajánlott megközelítés a legacy migrációhoz. Az új modul párhuzamosan készül, a forgalom fokozatosan kerül át a régiről az újra. A régi modul természetesen „meghal”, amikor már nem kap kéréseket. A minta minimalizálja a kockázatokat és lehetővé teszi a visszaállást problémák esetén.

Branch by Abstraction — technika, ahol absztrakció jön létre a régi és új implementáció felett. A klienskód átvált az absztrakcióra, a régi implementáció fokozatosan újra cserélődik. Példa: a hálózati réteg cseréje AFNetworking-ről Alamofire-re egy egységes NetworkService protokollon keresztül.

Fokozatos migráció — az átmenet kis lépésekre bontása: régi modul elrejtése → tesztek írása → új modul létrehozása → párhuzamos futtatás → régi modul eltávolítása. Minden lépés a rendszer stabil állapotával zárul, lehetővé téve a változtatások telepítését bármikor.