Легаси в разработке приложений — что это, риски и стратегии работы

Что такое легаси в разработке приложений

Легаси — код или система, которые продолжают работать в продакшене, но уже не соответствуют современным стандартам качества. Легаси может быть написано на устаревшем языке (например, Objective-C вместо Swift), использовать неподдерживаемые библиотеки или архитектурные паттерны, которые давно признаны антипаттернами.

Ключевое свойство легаси — отсутствие тестов. По определению Michael Feathers (2004), легаси-код — это код без тестов. Если нельзя безопасно изменить поведение, значит, система в статусе легаси независимо от возраста. Свежий код без unit-тестов — это легаси первого дня.

Легаси не обязательно плохо. Хорошо спроектированная система на 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 tests — первый шаг перед любым изменением легаси-кода. Запусти код на известных входных данных и запиши ожидаемый вывод. Эти тесты фиксируют текущее поведение как спецификацию. 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 lines of legacy code that should not be touched
        logPayment(payment) // sprout method
    }
    def logPayment(payment) {
        // new code added alongside legacy
    }
}

Миграция на современный стек технологий

Strangler Fig pattern — рекомендованный подход для миграции легаси. Новый модуль создаётся параллельно, трафик постепенно переключается со старого на новый. Старый модуль «умирает» естественно, когда перестаёт получать запросы. Паттерн минимизирует риски, позволяет откатиться при проблемах.

Branch by Abstraction — техника, при которой создаётся абстракция поверх старой и новой реализации. Код клиента переключается на абстракцию, старая реализация постепенно заменяется новой. Пример: замена сетевого слоя с AFNetworking на Alamofire через единый протокол NetworkService.

Поэтапная миграция — разбиение перехода на маленькие шаги: инкапсуляция старого модуля → написание тестов → создание нового модуля → параллельный запуск → удаление старого модуля. Каждый шаг завершается стабильным состоянием системы, что позволяет развернуть изменения в любой момент.