Legacy-код: что это и что с ним делать в 2026 году

Обновлено в ноябре 2026: статья переписана целиком — определение legacy-кода, семь способов модернизации, Strangler Fig, платформы без поддержки в 2025–2026 годах, российские требования (Указ № 166, 420-ФЗ), пример расчёта и пять схем.

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

Модернизация legacy-кода — способ выбраться из этого угла, не ставя компанию на кон переписывания. Из семи возможных шагов выбирают самый дешёвый, который решает реальную проблему, и чаще всего это не переписывание. Ниже — как мы принимаем такое решение вместе с клиентами: определения, стоимость, платформы, потерявшие поддержку в 2025–2026 годах, российские требования, семь способов модернизации, пример расчёта и случаи, когда код лучше не трогать.

Почему этот разбор пишет Фора Софт

Мы разрабатываем видеоплатформы, видеосвязь и продукты с ИИ с 2005 года: сдали больше 250 проектов, в команде около 50 инженеров. Большинство советов про legacy-код дают вендоры облаков, которым нужно продать платформу, и консультанты с почасовой оплатой. Ни тем, ни другим не приходится жить с результатом. Нам приходится: на нескольких продуктах мы остаёмся той же командой восемь, десять, двенадцать лет подряд, и каждое срезанное когда-то решение в итоге возвращается на наш же стол.

Такая длинная дистанция меняет советы. Мы модернизировали платформу распознавания музыки для диджеев с каталогом в 720 000 треков, не отключая её ни на день, и не раз отговаривали основателей от переписывания, которое съело бы год без новой пользы для пользователей. Когда продукт достаётся нам от другого подрядчика, мы берём его на поддержку и сопровождение и модернизируем по частям, не останавливая релизы.

Команды часто считают проблемой «старый код», а решением «переписать». Обычно неверно и то и другое. Дальше — как думать об этом правильно, с цифрами под каждое решение.

Legacy-код: что это простыми словами

Legacy-код — это код, который достался вам в наследство и который страшно трогать. Слово legacy по-английски значит «наследство». В русской речи инженеры говорят «легаси» или «унаследованный код», а заказчики чаще — «устаревший код».

Полезно различать два определения. Инженерное дал Майкл Физерс в книге «Эффективная работа с унаследованным кодом» (2004): legacy-код — это код без тестов, потому что без тестов его нельзя безопасно менять. Бизнесовое определение про деньги: код становится legacy, когда его изменение стоит дорого или несёт риск, как бы современно он ни выглядел.

Отсюда главный вывод: legacy — проблема стоимости, а не возраста. Приложение на React прошлого года без единого теста, автор которого уволился, уже legacy. Скучный, хорошо покрытый тестами сервис на C# 2014 года может им и не быть.

Legacy-код и технический долг связаны, но это не одно и то же. Технический долг — накопленные компромиссы, за которые команда платит при каждом изменении. Legacy-код — состояние системы, в котором этот долг и устаревшая платформа сделали изменения дорогими. Разбор долга на уровне отдельных модулей — в статье про рефакторинг кода простыми словами.

Что такое модернизация legacy-кода

Модернизация legacy-кода — это обновление старого ПО (его кода, платформы или архитектуры), чтобы оно дешевле обходилось, несло меньше рисков и снова могло принимать новые функции. Это спектр: от лёгкой чистки кода, который вы оставляете, до вывода системы из работы и перехода на готовый продукт. Когда работа касается всего продукта, а не одной кодовой базы, говорят о модернизации legacy-системы. Решения при этом те же.

Gartner описывает выбор как семь вариантов, упорядоченных по стоимости и по тому, насколько они вмешиваются в работу бизнеса. На рисунке 1 они собраны вместе, чтобы увидеть всё меню до того, как выбирать.

Рисунок 1. Семь вариантов модернизации: слева самые дешёвые и безопасные, справа самые дорогие и рискованные.

Во что обходится legacy-код

Счёт приходит из четырёх мест, и очевидно только одно. Первое — прямой налог. В исследовании McKinsey 2020 года ИТ-директора оценили технический долг в 20–40% стоимости всего технологического хозяйства компании, а на обход долга в затронутом коде команды тратят ещё 10–20% сверх бюджета любого проекта. В анализе McKinsey 2022 года по 220 компаниям те, кто лучше всех управляет техдолгом (верхние 20%), росли по выручке на 20% быстрее нижних 20%. Куда приводит запущенность, видно по госсектору США: в июле 2025 года Счётная палата США (GAO, отчёт GAO-25-107795) сообщила, что федеральные ведомства тратят около 80% своего ИТ-бюджета размером больше 100 млрд долларов в год на эксплуатацию существующих систем, а из 10 критичных legacy-систем, названных в 2019 году, к февралю 2025 года модернизированы только 3.

Второе — налог на найм. Если стек построен на мёртвом фреймворке, вы ищете людей с навыками, от которых рынок ушёл, и переплачиваете немногим, у кого они остались. Третье — налог на безопасность: платформа без поддержки перестаёт получать патчи, и известные уязвимости остаются открытыми. Четвёртое — налог упущенных возможностей, тихий и самый опасный. Любая функция делается дольше, потому что код сопротивляется, и вы выпускаете обновления медленнее конкурента, который модернизировался год назад.

Хрестоматийный пример устаревшей платформы: Flash. В июле 2017 года Adobe объявила, что прекращает развивать Flash Player, а 31 декабря 2020 года поддержка закончилась полностью. Продуктам на Flash пришлось либо переезжать на другие технологии, либо переписывать нужные компоненты с нуля. У каждого продукта есть срок жизни, и система без обновлений рано или поздно становится непригодной.

Последний налог растёт как сложный процент. Чем дольше нетронутый legacy-код лежит без внимания, тем дороже каждая новая функция: беспорядок растёт быстрее кодовой базы. Рисунок 2 показывает, как это выглядит и почему самый дешёвый момент действовать обычно сейчас.

Рисунок 2. Если долг копится, цена каждого изменения растёт; ранняя модернизация сбрасывает наклон кривой.

Если нужна цифра до того, как браться за работу, начните с аудита кода. Мы делаем экспресс-аудит бесплатно за 3 рабочих дня: он показывает устройство системы, находит действительно опасные модули и превращает «код плохой» в список с ценами, что исправлять и что оставить. Как устроен полный аудит, мы подробно разобрали в статье «Аудит кода: что это, как провести и по каким критериям оценивать».

Какие платформы стали legacy в 2025–2026 годах

Код становится legacy за одну ночь, когда его платформа перестаёт получать обновления безопасности, каким бы качественным он ни был. В 2025–2026 годах это случилось с несколькими самыми распространёнными стеками. Если ваш продукт работает на чём-то из таблицы, вы уже платите налог на безопасность. Даты взяты с официальных страниц жизненного цикла и проверены в ноябре 2026 года.

Конец поддержки — это срок для бизнеса, а не только для инженеров. Продукт на платформе без патчей трудно защитить, а цена утечки в России с 2025 года выросла кратно (подробнее в следующем разделе).

Legacy и российские требования: импортозамещение и 152-ФЗ

У российских компаний есть ещё два повода модернизировать legacy-систему, которых нет в западных руководствах. Первый — импортозамещение. По Указу Президента № 166 от 30 марта 2022 года с 1 января 2025 года органам власти и заказчикам по 223-ФЗ (госкомпаниям и их дочерним структурам) запрещено использовать иностранное ПО на значимых объектах критической информационной инфраструктуры. Если legacy-система держится на иностранной СУБД, ОС или middleware, вопрос «модернизировать или нет» для таких организаций уже решён — остаётся выбрать как.

Второй повод — ответственность за персональные данные. С 30 мая 2025 года действуют поправки в КоАП по Федеральному закону № 420-ФЗ: за утечку персональных данных назначают крупные штрафы, а за повторную утечку — оборотный штраф до 3% выручки, но не больше 500 млн рублей. Legacy-система с непропатченной платформой и данными клиентов внутри — ровно тот случай, когда старый код превращается в прямой финансовый риск.

Семь способов модернизировать legacy-код

Все семь вариантов, от дешёвого к дорогому. Прочитайте его целиком, прежде чем что-то решать: правильный ответ часто стоит на два-три шага левее, чем «переписать».

1. Обёртка (encapsulate). Старый код продолжает работать, но его закрывают чистым API, и новые системы общаются с обёрткой, а не с хаосом внутри. Самый дешёвый и безопасный вариант, он покупает время.

2. Перенос как есть (rehost). Тот же код переезжает на новую инфраструктуру, например со старого сервера в офисе на виртуальную машину в облаке. Код не меняется, риски хостинга снижаются.

3. Перенос с доработками (replatform). Переезд плюс небольшие безопасные правки под новую платформу: например, самостоятельно администрируемая база меняется на управляемую. Поведение то же, усилия умеренные.

4. Рефакторинг (refactor). Улучшение внутренней структуры кода, который вы оставляете, без изменения того, что он делает. Добавляем тесты, разбиваем класс-монстр, удаляем мёртвые ветки.

5. Новая архитектура (rearchitect). Код перестраивают в новую форму, например делят монолит на сервисы, чтобы части масштабировались и менялись независимо.

6. Переписывание (rebuild). Компонент пишут с нуля в прежних границах. Самый популярный первый порыв, хотя браться за него стоит в последнюю очередь.

7. Замена (replace). Систему выводят из работы и переходят на готовый продукт, который уже решает задачу. Иногда это самый честный и дешёвый ответ.

Можно ли модернизировать legacy-систему без переписывания?

Да. Большинство legacy-систем можно модернизировать, не переписывая исходный код. Пять из семи вариантов сохраняют то, что у вас есть: обернуть систему в API, перенести на поддерживаемую инфраструктуру как есть или с доработками, отрефакторить на месте под защитой тестов или заменять типовые модули по одному, пока ядро продолжает работать. Даже когда часть приходится переписать, Strangler Fig делает это по кусочку, а не разом.

• Платформа без поддержки, логика здоровая: rehost или replatform. Код переезжает, бизнес-правила не трогаем.
• С системой должны работать новые сервисы: обёртка. Тонкий API позволяет мобильным приложениям, партнёрам или ИИ-агентам пользоваться старой системой, не меняя её.
• Изменения идут медленно и страшно: рефакторинг маленькими шагами под защитой характеризационных тестов (пошагово — ниже).
• Одна из частей типовая: замените только её, например авторизацию или биллинг, а уникальный код оставьте.

Переписывание — исключение для платформы, у которой нет пути обновления. Если непонятно, к какому случаю относится ваша система, на этот вопрос как раз и отвечает аудит кода за одну-две недели.

Рефакторинг: чиним код, который оставляем

Рефакторинг меняет то, как код написан, но не то, что он делает. Это выбор по умолчанию для системы, которая по-прежнему окупается и работает на поддерживаемом стеке, но запуталась. Рискованный модуль закрывают тестами, а потом чистят маленькими обратимыми шагами: переименовывают непонятное, режут функцию на 900 строк, удаляют код, до которого не доходит ни один сценарий. Пользователи не замечают ничего, кроме того, что следующая функция выходит быстрее.

Дисциплина важнее инструментов. Рефакторинг идёт под защитой тестов, релизы выходят ежедневно, а рефакторинг и изменение поведения никогда не смешиваются в одном коммите. Если код вдобавок тормозит или падает под нагрузкой, мы берём его на доработку и оптимизацию ПО: стабилизируем хрупкие места и снимаем задержки, не останавливая продукт.

Как безопасно рефакторить legacy-код: пять шагов

Чтобы безопасно рефакторить legacy-код, сначала зафиксируйте его текущее поведение характеризационными тестами, а потом меняйте его маленькими обратимыми коммитами, в которых чистка не смешивается с новым поведением. Последовательность ниже повторяет алгоритм изменения legacy-кода из книги Физерса — по нему мы работаем с системами клиентов.

1. Найти точки изменения. Выписать конкретные файлы и функции, которые затронет ближайшее изменение для бизнеса. Рефакторить там, а не везде.
2. Найти точки проверки. Определить, где можно наблюдать результат работы кода: возвращаемое значение, строка в базе, ответ API, запись в логе.
3. Разорвать зависимости. Добавить «швы», чтобы код можно было запустить в тесте: выделить интерфейс, передавать часы или базу снаружи, обернуть статический вызов.
4. Написать характеризационные тесты. Зафиксировать, что код делает сейчас, включая ошибки, и проверять именно это. Такие тесты охраняют поведение, а не оценивают его.
5. Менять маленькими коммитами. Переименовывать, выделять, делить и удалять мёртвый код по шагу, прогонять тесты после каждого и выпускать ежедневно, а рискованные изменения прятать за фича-флагом.

Новый код, который нужен старому модулю, пишется в отдельной протестированной функции, а legacy-код её только вызывает (Физерс называет это «методом-отростком»). Так непротестированная масса не растёт. Первые черновики характеризационных тестов сейчас быстро пишут ИИ-ассистенты; мы всё равно проверяем каждый, как описали в статье о том, как мы применяем ИИ в тестировании, не накапливая технический долг.

Rehost и replatform: переносим почти как есть

Иногда с кодом всё в порядке, а проблема в том, на чём он стоит: ОС без поддержки, версия СУБД после конца жизни, дата-центр, из которого вы хотите уйти, или иностранный компонент, который нужно заменить. Rehost переносит тот же код на новую инфраструктуру. Replatform делает то же самое, но с небольшими продуманными правками, чтобы пользоваться новой платформой правильно: например, переходит на управляемую базу данных или объектное хранилище вместо самописного.

Ни то ни другое не улучшает код, да это и не нужно. За долю стоимости переписывания вы получаете поддерживаемую инфраструктуру, патчи безопасности и более простое масштабирование, не трогая бизнес-логику, которая уже работает. Часто это правильный первый шаг перед глубоким рефакторингом: он быстро останавливает кровотечение.

Переписать с нуля: соблазнительная ловушка

Полное переписывание выглядит чистым решением: выбросить хаос, начать заново, на этот раз сделать правильно. По словам Джоэла Спольски, это ещё и худшая стратегическая ошибка, которую может совершить компания-разработчик (эссе 2000 года). Netscape переписал браузер вместо того, чтобы чинить, почти три года не выпускал крупных релизов, так и не выпустил пятую версию и отдал рынок Internet Explorer, пока новый код ещё писался.

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

Замена: взять готовое вместо своего

Если система делает что-то типовое (почта, CRM, стандартная админка, готовая авторизация), самая дешёвая модернизация часто в том, чтобы перестать ею владеть. Замена выводит самописный код из работы и передаёт задачу продукту или сервису, который уже её решает и сам себя поддерживает.

Подвох в вашем конкурентном преимуществе. Заменяйте типовые части и никогда не трогайте код, за который вам платят клиенты. Платформа для диджеев может купить авторизацию, но не может отдать на сторону свой движок распознавания музыки. Весь навык в том, чтобы честно провести эту границу, и хороший аудит проводит её до того, как вы что-то подпишете. Российскому бизнесу при выборе готового продукта стоит заранее проверить, доступен ли сервис в России, как за него платить и где он хранит персональные данные.

Strangler Fig: модернизация без остановки продукта

Паттерн Strangler Fig («фикус-душитель») даёт почти все плюсы переписывания без заморозки. Мартин Фаулер назвал его в 2004 году в честь фикуса, который обвивает дерево, пока не заменит его целиком; паттерн описан и в руководствах AWS. Схема такая: перед старой системой ставят маршрутизатор, затем по одному переписывают куски поведения и переключают маршрутизатор на новый код, как только кусок доказал, что работает. Всё, что ещё не перенесено, по-прежнему обслуживает старая система.

Рисунок 3. Трафик переходит со старого монолита на новые сервисы по частям, без резкого переключения.

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

Рефакторинг, переписывание, перенос или замена: сравнение

Выбирайте поэтапную модернизацию вместо полного переписывания всегда, когда у старой системы есть живые пользователи, выручка или бизнес-правила, которые нигде не записаны: поэтапный путь даёт пользу через недели и его можно остановить на полпути, не оставшись ни с чем. Полное переписывание — только если у платформы нет пути обновления, ТЗ ясно и вы готовы оплатить месяцы до паритета по функциям.

Каждый вариант решают одни и те же вопросы: сколько усилий, какой риск простоя, сохраняется ли бизнес-логика, когда подходит. Вот они рядом.

Если читать таблицу сверху вниз, закономерность видна сразу: риск и усилия растут по мере того, как вы переходите от починки своего кода к его полной замене. Начинайте настолько высоко в списке, насколько позволяет ситуация.

Сколько стоит модернизация legacy-кода: пример расчёта

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

Рисунок 4. Диапазоны трудозатрат для одного приложения среднего размера. Переписывание разом примерно вдвое дороже Strangler Fig и при этом рискованнее.

Посчитаем на примере. Допустим, для шестилетнего SaaS без тестов вы выбрали Strangler Fig: по рисунку 4 это 16–40 инженеро-недель, то есть от 640 до 1600 часов при 40-часовой неделе. При условной средней ставке 3000 рублей в час (подставьте свою) нижняя граница — около 1,9 млн рублей, верхняя — около 4,8 млн рублей. Переписывание того же приложения разом (30–58 недель, 1200–2320 часов) обойдётся примерно в 3,6–7 млн рублей и всё это время будет держать дорожную карту замороженной.

Чтобы цифры стали реальными, нужны две поправки. Первая — аудит кода в начале (одна-две недели), чтобы оценка опиралась на факты, а не на ощущения; как оценивать кодовую базу перед вложениями, разобрано в чек-листе аудита кода из 12 пунктов. Вторая — запас на неизвестное: почему оценки разработки промахиваются и как читать смету, мы объяснили в статье «Почему разработчики ошибаются в оценках». Если подрядчик называет фиксированную цену переписывания без аудита — это тревожный знак, а не выгодное предложение.

Как ИИ меняет модернизацию legacy в 2026 году

ИИ сильно удешевил механическую часть модернизации. Это меняет расчёт, но не стратегию. Инструменты 2026 года реальны и продаются. Amazon Q Developer обновляет код на Java 8, 11 и 17 до Java 17 или 21 с пошаговыми диффами. Соседний сервис AWS Transform документирует недокументированный COBOL, разбирает мейнфреймовые монолиты, а после обновления в декабре 2025 года выполняет пользовательские преобразования любого кода; по заявлению AWS, полная модернизация Windows-приложений идёт до 5 раз быстрее. IBM watsonx Code Assistant for Z переводит мейнфреймовый COBOL на Java. GitHub Copilot app modernization, общедоступный с сентября 2025 года, оценивает приложения на Java и .NET, обновляет фреймворки и зависимости, чинит сборку и упаковывает результат в контейнер.

Для российских команд оговорка: доступ к облачным сервисам AWS, GitHub и IBM из России и оплата их подписок ограничены, а отправлять код с персональными данными во внешние сервисы нельзя без оценки рисков по 152-ФЗ. Поэтому на практике часть таких задач решают локально развёрнутыми моделями и ассистентами внутри контура компании.

В чём ИИ действительно силён: писать недостающие тесты, которые делают старый код безопасным для изменений; генерировать документацию к системам, авторы которых ушли; обновлять фреймворки и библиотеки; делать черновик выделения сервиса. Раньше именно эта рутина делала модернизацию медленной и дорогой.

Чего ИИ не умеет: решать, рефакторить или переписывать; понимать, зачем существует странное правило, прежде чем его удалить; выпускать код без ревью. Сгенерированному ИИ коду миграции по-прежнему нужны человек, набор тестов и ревью, иначе вы просто быстрее меняете старый долг на новый. При правильном использовании ИИ усиливает стратегию из этого руководства, но не заменяет её.

Как выбрать подход: пять вопросов

Отвечайте сверху вниз. Первое «нет» обычно прямо указывает на нужный шаг, а рисунок 5 превращает ту же логику в схему, которую можно отдать команде.

Рисунок 5. Пять вопросов в виде дерева решений: идите по стволу и сворачивайте на первом «нет».

1. Система ещё приносит пользу бизнесу? Если нет, выведите её из работы. Не тратьте ни рубля на модернизацию того, что скоро отключите.

2. Платформа, среда исполнения и стек ещё поддерживаются? Если нет, сначала перенесите систему (replatform или rehost), а уже потом вкладывайтесь в код поверх платформы.

3. Бизнес-логику стоит сохранять? Если нет, потому что система делает типовую работу, замените её продуктом, созданным для этой задачи.

4. Код можно безопасно менять уже сегодня: есть тесты и разумная модульность? Если да, рефакторьте на месте, фундамент уже есть.

5. Живые пользователи не дают заморозить код? Если да, используйте Strangler Fig. Полное переписывание заслуживает места, только если заморозка возможна, ТЗ ясно и есть реальный запас времени и денег. Сомневаетесь — возьмите второе мнение до того, как выделять бюджет.

Пример из практики: платформа на 720 000 треков

Ситуация. Franchise Record Pool — платформа для диджеев с распознаванием музыки по принципу Shazam и каталогом больше 720 000 лицензированных треков от Sony Music, Universal, Virgin и других лейблов. Ей каждый день пользуются работающие диджеи, включая Funkmaster Flex. Отключить продукт на время модернизации было нельзя, а правообладатели не потерпели бы простоя каталога.

План. Вместо переписывания мы модернизировали систему вокруг работающего продукта: заменяли части за живой системой, и диджеи всё это время продолжали работать. Каждый кусок выходил в продакшен и доказывал, что работает, прежде чем начинался следующий. Это дисциплина Strangler Fig на реальном бизнесе с каталогом. Подробно проект разобран в статье «FRP SPINS: как мы обновили платформу Shazam для диджеев».

Результат. Современная платформа распознавания и каталога, которая по-прежнему обслуживает профессиональных диджеев и соответствует лицензионным требованиям крупных лейблов, сделанная без заморозки, которую потребовало бы переписывание разом. Если ваш legacy — тоже медиапродукт, устройство звукового тракта, от кодеков до синхронизации дорожек, подробно разобрано в нашем курсе «Аудио для видео».

Пять ошибок, которые губят модернизацию

1. Переписывать до аудита. Команда решает «переписываем» по ощущению, насколько плох код, а посреди работы выясняет, какие части были несущими. Сначала аудит, чтобы стратегия опиралась на факты.

2. Модернизировать без тестов. Менять legacy-код без страховки значит рисковать новой ошибкой при каждом исправлении, и найдёт её клиент, а не вы. Сначала характеризационные тесты: именно они делают код безопасным для изменений.

3. Переключаться разом. Переход со старого на новое за одни выходные собирает все риски в одну ночь. Мигрируйте постепенно, чтобы каждый шаг был маленьким и обратимым.

4. Модернизировать типовое вместо уникального. Лучшие инженеры переписывают авторизацию или рассылки, а основной продукт стоит на месте. Типовое заменяйте, в уникальное вкладывайтесь.

5. Откладывать миграцию данных. В старых системах годами копятся грязные и ценные данные, и перенести их аккуратно часто труднее, чем код. Планируйте путь данных с первого дня, а не за неделю до запуска.

Метрики: как понять, что модернизация работает

Скорость поставки. Отслеживайте время от коммита до продакшена и частоту релизов — две из четырёх метрик DORA. Модернизация работает, когда обычная функция, на которую уходило три недели, выходит за три дня, а релизы из ежемесячных и страшных становятся ежедневными и скучными.

Качество и надёжность. Отслеживайте долю неудачных изменений и среднее время восстановления. Покрытие тестами в затронутых модулях должно расти от нуля до уровня, при котором зелёная сборка действительно что-то значит. Число инцидентов в месяц должно снижаться.

Бизнес. Отслеживайте, какую долю времени инженеров съедает поддержка, а какую — новая работа: здоровый сдвиг идёт от «большая часть уходит на то, чтобы всё не упало» к «большая часть уходит на новую ценность». Добавьте стоимость хостинга на активного пользователя и время ввода нового инженера в проект: обе цифры должны падать по мере того, как код становится понятнее.

Когда legacy-код лучше не трогать

Иногда правильный шаг — ничего не делать, и компания, которая продаёт только модернизацию, вам этого не скажет. Если система стабильна, дёшево обходится, редко меняется и не несёт рисков безопасности, оставьте её в покое. «Старый» — не повод тратить деньги: скучная и работающая система — это достоинство, а не недостаток.

Подождите и тогда, когда не можете сформулировать результат для бизнеса. «Код некрасивый» — не цель, а «нам нужен единый вход, и модуль авторизации его блокирует» — цель. Модернизируйте ту часть, которая стоит между вами и реальной задачей, и только её. Если всю систему выводят из работы в следующем году, не модернизируйте её вовсе, а доработайте до конца срока.

Исключение одно: безопасность. Платформа без поддержки с известными незакрытыми уязвимостями — это не «скучно и работает», а утечка, которая ждёт своего часа. Одного этого достаточно, чтобы оправдать перенос, даже если других причин нет.

Частые вопросы о legacy-коде

Что такое legacy-код простыми словами?

Legacy-код — это унаследованный код, который работает, но который стало дорого и рискованно менять: нет тестов и документации, авторы ушли, платформа не получает обновлений. Возраст вторичен: проект прошлого года без тестов тоже может быть legacy.

Чем legacy-код отличается от технического долга?

Технический долг — это накопленные компромиссы в коде, за которые команда платит при каждом изменении. Legacy-код — состояние системы, в котором долг и устаревшая платформа сделали изменения дорогими и опасными. Долг бывает и в новом коде, а legacy — его запущенная стадия.

Что лучше: рефакторинг legacy-кода или переписать с нуля?

Рефакторинг, если система по-прежнему подходит бизнесу и работает на поддерживаемом стеке: вы сохраняете всю накопленную логику и начинаете выпускать функции быстрее. Переписывать стоит, только если платформа мертва или предметная область изменилась в корне, и даже тогда лучше поэтапно, по паттерну Strangler Fig.

Сколько стоит модернизация legacy-системы?

Оценивайте в инженеро-неделях и умножайте на свою ставку. Для приложения среднего размера рефакторинг занимает примерно 6–14 недель, Strangler Fig — 16–40, переписывание разом — 30–58. При условной ставке 3000 рублей в час путь Strangler Fig стоит около 1,9–4,8 млн рублей. Точную цифру для вашей системы даёт аудит кода.

Что такое паттерн Strangler Fig?

Strangler Fig, описанный Мартином Фаулером в 2004 году, заменяет legacy-систему постепенно: перед ней ставят маршрутизатор, по одному переписывают куски поведения и переводят на новый код трафик, когда кусок доказал, что работает. Старая система обслуживает пользователей всё это время, поэтому нет ни резкого переключения, ни заморозки.

Сколько длится модернизация legacy-кода?

Аудит кода занимает одну-две недели. Дальше всё зависит от пути: рефакторинг приложения среднего размера — часто 6–14 инженеро-недель, поэтапная замена по Strangler Fig — 16–40. Strangler Fig даёт результат непрерывно, поэтому польза видна через недели, а не в один день в конце.

Может ли ИИ модернизировать legacy-код автоматически?

ИИ ускоряет механическую часть: пишет недостающие тесты, документацию, обновляет фреймворки и готовит черновики выделения сервисов (Amazon Q Developer, AWS Transform, GitHub Copilot app modernization, IBM watsonx Code Assistant for Z). Стратегию он не выбирает, а его код без тестов и ревью выпускать нельзя.

Можно ли модернизировать систему, не переписывая исходный код?

Да. Обёртка в API, перенос как есть или с доработками, рефакторинг на месте под защитой тестов и замена типовых модулей по одному сохраняют существующий код. Переписывание действительно нужно только платформе без пути обновления, и даже тогда Strangler Fig делает это по частям.

Какие платформы потеряли поддержку в 2025–2026 годах?

.NET 8 и .NET 9 теряют поддержку 10 ноября 2026 года, Node.js 20 — 30 апреля 2026 года, Python 3.10 — 1 октября 2026 года, PHP 8.1 — 31 декабря 2025 года, платные обновления для Windows Server 2012 и 2012 R2 закончились 13 октября 2026 года. Продукты на этих платформах больше не получают патчей безопасности.

Как безопасно рефакторить legacy-код?

Зафиксируйте текущее поведение характеризационными тестами, разорвите зависимости, чтобы код запускался в тесте, и рефакторьте маленькими коммитами, не смешивая чистку с новыми функциями. Трогайте только код, который затрагивает ближайшее изменение для бизнеса, а рискованные части выпускайте за фича-флагами.

Что делать с legacy-кодом: итог

Legacy — проблема стоимости, а не возраста, и способов её решить семь, а не два. Начинайте как можно левее на спектре: обёртка или перенос останавливают кровотечение, рефакторинг чинит код, который ещё подходит бизнесу, типовые части заменяются готовыми продуктами, а переписывание остаётся для платформы, которая действительно мертва. Когда большие изменения нужны живому продукту, Strangler Fig даёт их без заморозки. Для российских компаний к этому добавляются сроки импортозамещения и штрафы за утечки, которые делают платформу без патчей прямым финансовым риском.

Шаг, который снижает риск всего остального, — начать с аудита кода, а не с переписывания, чтобы стратегия опиралась на факты. С этого мы начинаем с каждым клиентом и честно говорим, если правильный ответ — оставить ваш код в покое.

Что почитать дальше