Легаси у развоју апликација — шта је то, ризици и стратегије рада

Шта је легаси у развоју апликација

Легаси — код или систем који наставља да ради у продукцији, али више не испуњава савремене стандарде квалитета. Легаси може бити написан у застарелом језику (нпр. Objective-C уместо Swift), користити неподржане библиотеке или архитектонске шаблоне који су одавно препознати као анти-шаблони.

Кључно својство легасија је недостатак тестова. По дефиницији Michael Feathers (2004), легаси код је код без тестова. Ако се понашање не може безбедно променити, систем је у статусу легаси без обзира на старост. Свеж код без јединичних тестова — легаси је првог дана.

Легаси није нужно лош. Добро пројектован систем у Java 8 може бити поузданији и разумљивији од хаотичног кода у Kotlin-у са корутинама. Старост кода није показатељ квалитета — важно је колико се систем подвргава променама и проширењу.

Зашто је легаси код нормалан

Сваки успешан систем временом постаје легаси. То је природан процес: технологије се развијају брже него што код може бити преписан. Апликација написана пре 5 година у Swift 2 данас је легаси, иако је у тренутку настанка била савремена.

Пословна вредност легасија се често потцењује. Систем стабилно ради, обрађује трансакције, чува податке — преписивање носи ризике. Према Standish Group (2024), 35% пројеката потпуног преписивања завршава неуспехом. Економски је оправдано не ослободити се легасија, већ научити радити са њим.

Најбоље стратегије — постепена миграција, инкапсулација старог кода иза нових интерфејса и аутоматизовано тестирање. Легаси постаје проблем само када престане да се подвргава променама са предвидљивом ценом.

Главни знаци легаси система

Недостатак аутоматских тестова — главни индикатор. Ако након промене једне линије кода програмер не може да покрене тестове и увери се да ништа није покварено — пред вама је легаси. Додатни знак: процедура деплоја траје сатима и захтева ручне радње.

Документација не одговара коду — још један маркер. Архитектонски дијаграми су застарели, коментари описују понашање које се већ променило. Time-to-ramp-up за новог програмера прелази месец дана — знак високе сложености и ниске одржаваности система.

Додатни знаци: монолитна архитектура без јасних граница, ручно тестирање као главни метод провере, дугачак CI пајплајн (више од 30 минута), коришћење библиотека без актуелних верзија и немогућност ажурирања зависности без ломљења суседних модула.

Феномен „крхког кода” — промена на једном месту ломи три друга. То је последица чврсте повезаности (tight coupling), када модули знају превише један о другом. Што је coupling већи, то систем брже прелази у категорију легасија.

Ризици рада са застарелим кодом

Смањење брзине — главни ризик. Додавање једноставне функције захтева сате проучавања кода и дане тестирања. Према Stripe (2024), програмери троше 33% времена на превазилажење техничког дуга, који је директно повезан са присуством легаси модула у пројекту.

Одлив експертизе — аутори оригиналног кода одлазе из компаније, а документација је непотпуна. Нови програмери се боје да дирају неразумљиве модуле, што доводи до ефекта „замрзнутог кода”: модул се не развија, али наставља да ради. Bus factor таквих система је критично низак.

Безбедност — застареле библиотеке садрже познате рањивости. Коришћење OpenSSL 1.0.2 или застарелих верзија Jackson-а у Java пројектима је директан пут до безбедносних инцидената који могу коштати посао репутације и клијената.

Демотивација тима — рад са легасијем без стратегије његовог побољшања смањује задовољство програмера. Тим престаје да буде поносан на производ, флуктуација кадра расте, што још више успорава развој система.

Стратегије рефакторинга легасија

Characterization тестови — први корак пре било какве промене легаси кода. Покрени код на познатим улазним подацима и забележи очекивани излаз. Ови тестови бележе тренутно понашање као спецификацију. Golden master testing — варијанта где се излазни подаци упоређују са референтним фајлом.

Seam анализа — тражење тачака где се повезаност може прекинути без промене понашања. Michael Feathers издваја неколико типова seam: preprocessor seam, object seam, link seam. Object seam — најчешћи: замена реалног објекта тест заглушком преко интерфејса.

Sprout method и Sprout class — технике додавања новог кода поред старог, а не унутар њега. Уместо измене постојеће методе, креирај нову методу са потребном логиком и позови је из старе. Тиме се минимизира ризик од ломљења радног кода.

Пример: додавање логирања у легаси

class LegacyPaymentProcessor {
    def process(payment) {
        // 200 линија легаси кода које не треба дирати
        logPayment(payment) // sprout method
    }
    def logPayment(payment) {
        // нови код додат поред легасија
    }
}

Миграција на савремени технолошки стек

Strangler Fig шаблон — препоручени приступ за миграцију легасија. Нови модул се креира паралелно, саобраћај се постепено преусмерава са старог на нови. Стари модул природно „умире” када престане да прима захтеве. Шаблон минимизира ризике и омогућава повратак у случају проблема.

Branch by Abstraction — техника у којој се креира апстракција изнад старе и нове имплементације. Клијентски код се пребацује на апстракцију, стара имплементација се постепено замењује новом. Пример: замена мрежног слоја са AFNetworking на Alamofire кроз јединствени протокол NetworkService.

Постепена миграција — подела транзиције на мале кораке: инкапсулација старог модула → писање тестова → креирање новог модула → паралелно покретање → уклањање старог модула. Сваки корак се завршава стабилним стањем система, што омогућава примену промена у било ком тренутку.