Вакансии пахнут новизной: фронтенд-фреймворки, контейнеры, нейросети, микросервисы. Рабочие места часто устроены иначе: расчётные батчи, база в работе с 2011 года, код, авторы которого давно сменили компанию. Разрыв между витриной рынка и содержимым реальных проектов рождает вредный карьерный совет: беги от старого кода, он тормозит развитие. На практике именно унаследованные системы дают навыки, которые почти не тренирует зелёный проект, и именно эти навыки рынок потом покупает по повышенной цене. Разберём, чем ценен легаси-опыт, как его набирать без потерь и где проходят его границы.
Сколько на самом деле живёт промышленный софт
Сроки жизни промышленного софта измеряются не годами, а поколениями инженеров. PostgreSQL поддерживает каждую мажорную версию пять лет после релиза и выпускает мажорные версии примерно раз в год: версия 9.6, вышедшая в сентябре 2016 года, дожила до ноября 2021 года. Мажорное обновление там всегда отдельная задача: каталоги данных несовместимы между версиями, нужен pg_upgrade или выгрузка с последующей загрузкой, зато перепрыгивать можно сразу через несколько мажорных версий, изучив заметки о промежуточных релизах. Java показывает ещё более длинную шкалу: JDK 8 вышла в марте 2014 года, дистрибутивы поддерживают её до сих пор, а Eclipse Temurin обещает обновления безопасности до декабря 2030 года; полугодовой ритм релизов платформы действует с 2017 года, статус долгосрочной поддержки носят версии 8, 11, 17, 21 и 25.
Рядом с ними знаковые даты окончаний поддержки: Python 2 перестала получать обновления 1 января 2020 года, AngularJS в январе 2022 года, Internet Explorer в июне 2022 года. А сверху самый показательный слой: COBOL, язык 1960 года рождения, в 2023 году получил новый международный стандарт ISO/IEC 1989:2023, а в 2025 году коллекция компиляторов GCC 15 обзавелась фронтендом для него. Языку за шестьдесят, а индустрия продолжает выпускать под него новые инструменты. В историю наследия входит и происхождение: среди авторов первой спецификации была Джин Саммет, а корни идей восходят к работам Грейс Хоппер.
Вывод из этих цифр скучный и полезный: легаси это не эксклюзив неудачных компаний, а основная масса работающего кода. Средний возраст системы в банке, страховой или логистике измеряется десятилетием, и инженер, умеющий только начинать проекты, вынужден искать места, где проекты начинают. Таких мест заметно меньше, чем мест, где системы обслуживают, развивают и мигрируют.
Почему старый код учит быстрее зелёного проекта
У старой системы жёсткие ограничения, и именно они качают инженерные мышцы. Переписать с нуля нельзя: система обрабатывает платежи и расписания, изменения обязаны быть безопасными. Уронить нельзя: час простоя стоит дороже, чем месяц разработки. Скорость изменений важнее скорости написания, каждый коммит это аккуратное вмешательство в живую систему.
Отсюда растут навыки, которые почти не даёт новый проект. Чтение чужого кода как основной способ понимания: документация устарела, авторы ушли, код остался единственным свидетелем замысла. Отладка в условиях бедных логов, по следам в самих данных. Работа по схеме "предположение, проверка, вывод" вместо слепого перебора. Археология требований: не "как должно быть", а "почему сейчас работает именно так", потому что у каждой странности старой системы когда-то была причина. Оценка рисков изменения: что тронешь, то и поедет, и лучше узнать это до релиза, а не после.
Классическая сцена: ночной расчётный батч раз в месяц падает на ровном месте, воспроизводится только на полных объёмах, на разбор дали четыре часа и одного дежурного. Инженер за такое дежурство осваивает то, что в новом проекте не встретится за год: сужение диапазона поиска, изоляцию подозрительных шагов, чтение метрик, дисциплину откатываемых изменений. После пары таких ночей атомарные коммиты и выключатели функциональности перестают быть догмой, они становятся инстинктом самосохранения.
Старая система учит и производительности, потому что у неё есть то, чего нет у зелёных проектов: реальные объёмы. Запрос, который на тестовой базе отрабатывает за миллисекунды, на таблице с четырьмя сотнями миллионов строк ведёт себя иначе, и разница между планами выполнения в PostgreSQL становится не теорией из учебника, а ежедневной работой. Инженер, который объяснил заказчику, почему отчёт выгоднее считать заранее, а не на лету, получает опыт, который переносится в любой стек и в любую компанию.
Отдельный пласт, самый недооценённый: отношения с данными. В старой системе данные почти всегда дороже кода, мигрировать их страшнее, чем переписать логику, и инженер, который провёл хотя бы одну миграцию таблиц с миллиардами строк, понимает цену обратной совместимости на уровне рефлексов. Зелёный проект таких уроков не даёт, там данных ещё нет.
Миграция с Java 8 на актуальную версию как отдельный инженерный проект
Самый массовый легаси-кейс корпоративной разработки, перевод Java-приложения с восьмой версии на современную, снаружи выглядит как обновление цифры в конфигурации. Внутри это полноценный проект. Spring Boot 2.7 прекратила получать открытые обновления в ноябре 2023 года, третья линейка требует Java 17, и вместе с платформой мигрирует пространство имён: префикс javax по всей кодовой базе превращается в jakarta.
// до миграции
import javax.validation.constraints.NotNull;
// после миграции
import jakarta.validation.constraints.NotNull;Аудит перед переходом запускают штатной утилитой из состава JDK:
jdeps --jdk-internals target/app.jar
jdeps --print-module-deps target/app.jarПричина переименования сама по себе поучительна: Oracle передала Java EE фонду Eclipse, платформа сменила имя на Jakarta EE, а с релиза Jakarta EE 9 в декабре 2020 года пространство имён переехало из javax в jakarta. За сухой заменой импортов стоит кусок истории индустрии, и легаси-инженер разбирается в ней по необходимости.
Первая команда показывает использование внутренних интерфейсов JDK, от которых предстоит избавиться, вторая собирает список модулей под новый рантайм. Дальше план из привычных инженерных шагов: характеристические тесты фиксируют текущее поведение, зависимости обновляются по одной, платформа меняется после зелёного прогона, сервер приложений уходит последним. Финальный штрих, параллельный запуск старой и новой версии на одинаковых входных данных со сверкой результатов и готовый план отката. Проект занимает месяцы, и инженер, прошедший его один раз, перестаёт бояться слова "миграция" навсегда.
Приёмы безопасной работы с унаследованным кодом
Инструментарий легаси-инженера развитой и почти целиком переносится между проектами и стеками:
- характеристические тесты фиксируют текущее поведение до изменений, чтобы рефакторинг не поменял то, о чём не просили;
- бинарный поиск по истории коммитов находит точку появления ошибки за десяток шагов вместо недели чтения диффов;
- статический анализатор вроде SonarQube подсвечивает самые рискованные места, с которых начинают планомерную зачистку;
- параллельный запуск старой и новой реализации на одинаковых входных данных со сверкой результатов даёт уверенность без полного переписывания;
- постепенное замещение функциональности по одной подсистеме за раз вместо одномоментного переключения всего целиком.
Бинарный поиск по коммитам умещается в три команды:
git bisect start
git bisect bad HEAD
git bisect good v2.3.1Дальше утилита сама выбирает промежуточные коммиты, инженер помечает каждый как исправный или сломанный, диапазон сокращается вдвое на каждом шаге. Метод работает в любом репозитории с читаемой историей и экономит самый дорогой ресурс инженера, время.
Поверх отдельных приёмов работает простое правило бойскаута: оставляй систему чуть чище, чем она была до твоего касания. Одна правка, один мелкий рефакторинг рядом, один добавленный тест. Правило не превращает болото в сад за месяц, но гарантирует, что система не деградирует, а беспорядок уменьшается на каждом шаге.
Реальная карьерная цена легаси-опыта на рынке труда
Спрос на людей, которые не боятся старых систем, устойчивый: банки, страховые, ретейл, телеком, промышленность. Там, где система зарабатывает десятилетиями, новичок со свежим стеком бесполезен первые месяцы, а инженер с опытом поддержки приносит пользу с первой недели. COBOL-разработчики на финансовом рынке стали дефицитом не из-за сложности языка, а потому что носители опыта уходят на пенсию быстрее, чем пополняются. Редкость опыта поднимает ставку, это обычная экономика спроса.
Премия приходит не за факт работы со старым, а за решённые задачи. Формулировки решают всё: "поддерживал учётную систему" звучит как расплата, "перевёл расчётный модуль с Java 8 на 17 без остановки выплат" звучит как достижение. Легаси-резюме стоит писать в терминах результатов: сколько стоила эксплуатация до и после, как изменилось время сборки, сколько инцидентов ушло, какие миграции проведены без простоя. Такие фразы читаются с той же скоростью, что и модные ключевые слова, но за ними стоит проверяемая работа.
На собеседованиях старшего уровня легаси-опыт читается по вопросам, которые кандидат задаёт сам. Человек, разобравший пару старых систем, спросит про объём данных, про частоту релизов и про историю миграций, а не только про стек. Для нанимающего это самый быстрый способ отличить инженера от коллекционера технологий, и выигрывает тут чаще первый.
Обратная сторона тоже реальна: выгорание стажа. Десять лет одинаковой эксплуатационной рутины без развития дают десять лет стажа и один год опыта, повторённый десять раз. Легаси-карьера съедает человека там, где нет миграций, автоматизации и роста сложности. Рецепт простой: чередовать поддержку с проектами улучшения, автоматизировать рутину скриптами, раз в два-три года проводить заметную миграцию и фиксировать её в резюме.
Когда мода на новые фреймворки обманывает разработчика
У гонки за новыми инструментами есть скрытая цена, о которой не пишут в анонсах. Каждый новый фреймворк в стеке это ещё одна точка отказа, ещё одна кривая обучения для команды и ещё один кандидат в легаси через пять лет. Известный принцип "выбирайте скучные технологии" говорит ровно об этом: новинка обязана окупать собственный риск, а по умолчанию выигрывает проверенное и скучное. Проект на зрелых решениях обычно доставляет функции быстрее, чем проект, который первые полгода разворачивает модный стек.
Второй драйвер обновления часто не технический, а резюме-технический: в стек добавляют слово модного фреймворка, чтобы на собеседовании говорить про него. Честный вопрос перед выбором технологии: какую конкретную проблему это решает и сколько будет стоить уход, когда мода пройдёт. Технологии живут по циклу: громкий анонс, переоценённые ожидания, разочарование, рабочая зрелость. В легаси-мире инструменты чаще всего встречаются на четвёртой фазе, когда самые неудобные сюрпризы уже собраны другими.
У легаси-болота тоже есть диагноз: система без тестов, без ревью, без наблюдаемости и без плана развития. Старость кода тут не причина, а симптом заброшенной инженерной культуры. Исправляется это не переписыванием с нуля, а возвращением базовых практик: характеристические тесты на критичных участках, конвейер сборки, разбор инцидентов, понятный план миграций. После этого и старая система превращается в место силы, а в карьере появляется репутация человека, который приводит хаос в порядок.
Мода на новейшие фреймворки меняется каждые несколько лет, а системы живут десятилетиями, и между этими двумя временными шкалами строится настоящая инженерная карьера. Легаси-опыт это школа ограничений, школа чтения чужого кода и школа безопасных изменений, и он конвертируется в деньги прямее, чем строчка с модным словом в резюме. Сильная траектория выглядит скромно: сначала научиться не ломать работающее, потом научиться улучшать его по частям, затем провести хотя бы одну крупную миграцию от начала до конца. Такой инженер не зависит от капризов моды, его навык звучит просто: он заставляет старое работать и готовит ему смену.