Привет, Хабр! Меня зовут Саша Мищенко, я тимлид платформенной команды в Профи.ру. Сегодня хочу поговорить о легаси — о том, как мы к нему относимся и как уживаемся в одной компании.
Чего точно не будет в этом тексте: страшилок о том, как мы потеряли кучу денег из-за старого кода, и геройских историй про то, как я проснулся и решил переписать всё с нуля.
Вместо этого я хочу рассказать:
почему мы не переписываем код просто из-за того, что он старый;
как балансируем между быстрыми релизами и долговечной архитектурой;
какие фейлы происходят, когда команду уносит в одну из крайностей.
Поехали.
Зачем вообще снова говорить о легаси?
Пока мы пишем код, тема легаси будет на поверхности. Любой разработчик в среднем и крупном бизнесе живёт с одной и той же мыслью: «Надо бы побыстрее, но не хочется влезать в техдолги».
Это может пугать, расстраивать и дизморалить. Но легаси есть почти везде. Если код живёт достаточно долго, он становится частью истории продукта. Меняются разрабы, требования рынка, стек, а кодовая база, как верблюд, тянет на себе всё это разнообразие времён и подходов.
Есть пруфы: 64% важных для компаний инструментов написано на легаси. До сих пор! И у этого есть причина: золотое правило — «Не сломано — не трогай».
25 лет назад Джоэл Спольски предостерёг разработчиков от полного переписывания кода, который работает. Всё ещё актуально (но не всегда).
В старом, с виду страшненьком, но рабочем коде живут накопленные годами знания, обработка корнер-кейсов и следы того, как ведут себя реальные пользователи. Выкинул функцию на 200 строк — и внезапно выяснил, что она держала на себе половину сервиса.
Если уж и переписывать, то за что-то очень понятное и осязаемое: скорость поставки, безопасность, масштабирование. Да и то постепенно.
Но иногда соблазн велик: выбросить всё, создать новую папку и на год исчезнуть в прекрасной новой архитектуре. Признайтесь, бывало такое желание?
О фейлах и людях
Не буду говорить о старых известных кейсах вроде Netscape: хочется свежих историй.
14 июля Cloudflare уронила публичный резолвер 1.1.1.1 на 62 минуты. Корень проблемы — баг от 6 июня. Пока систему не трогали, он себя не проявлял. Но когда запустили общее обновление, то оно сузило список рабочих площадок до одной, тестовой. И она, естественно, была недоступна, потому что предназначена для теста. Отсюда и массовый сбой.
При чём тут легаси? Поломка случилась на стыке старой и новой систем, которые вместе управляют инфраструктурой. Старая часть опиралась на жёсткие списки дата-центров и не умела выкатывать изменения постепенно, поэтому ошибка ударила сразу глобально.
Из хорошего: в Cloudflare быстро восстановили анонсы по всему миру. Но, что самое главное, они написали подробный postmortem. Рассказали о том, что случилось и как так вышло. Это сработало, в основном пользователи даже не разозлились:
Или вот:
Есть и другой кейс, обезличенный, но не менее показательный. Пользователь ИТ-форума рассказал, как в его стартапе с выручкой $100 млн решили всё переписать на микросервисы на Ruby.
Чтобы ускорить миграцию, на несколько лет фактически запретили коммитить в основной сервис. Ожидаемого положительного влияния на выручку не произошло — наоборот, она снизилась.
По итогу вся эта авантюра съела весь раунд инвестиций (Series D) и три года разработки. Пу-пу-пу…
И в целом неудивительно. Нашёл исследование от VFunction за 2022 год, где говорится о том, что 79% попыток модернизировать кодовую базу проваливаются. Конечно, за три года ситуация могла измениться, но не факт, что в лучшую сторону. Может быть, риски и стали меньше благодаря возможностям ИИ, но сам человеческий подход остался прежним — 100%.
Делаю такой вывод из ещё одного свежего (почти) кейса.
Ситуация. У компании есть легаси-дашборд: до первого рендера — около четырёх секунд ожидания с белыс экраном, а ещё старые виджеты. Приняли решение починить.
Разработчики ожидаемо предлагали менять итерациями, но бизнес попросил быстро, красиво и сразу.
В итоге сломали биллинги по триалам, удалили фичу, которая оказалась очень даже нужна юзерам, и словили кучу багов разом.
Из плюсов: вынесли важные уроки из этой ситуации и больше так не делают. Из минусов — всё остальное.
Модернизация с хорошим концом
Но мир легаси не без чудес. Вот парочка свежих примеров.
Весной 2025-го исследователи взяли большой кусок COBOL и прогнали его через LLM-пайплайн, чтобы получить эквивалент на Java. Чтобы было проще читать и легче масштабировать.
Каждый файл при этом проверили через автотесты.
В итоге 93% переведённых модулей после сборки и тестов вели себя так же, как исходник. Для сравнения: ручками получилось ~75%.
Да ещё и намного быстрее.
Не всё, конечно, шло гладко: иногда ИИ не справлялся и путался в коде. Но с такой точностью можно и потерпеть.
Почитать подробнее о кейсе можно тут.
Аналогичная история у Google. Благодаря LLM они смогли провести внутренние миграции и перейти с 32-битных цифр на 64-битные. Вручную это бы заняло вечность.
Как это делают профи
Но оба предыдущих кейса — не о переписывании кода с нуля, а о точечных модернизациях. Для меня это единственный безопасный вариант, и я железно придерживаюсь его в Профи.ру.
Пришло время рассказать не о том, как у других, а о том, как у нас.
Внутри мы разделяем разработчиков на два больших кластера: продуктовую и платформенную команды.
Продуктовые отвечают за новые фичи и поддержку действующего функционала — за всё, что видит или увидит пользователь.
Мы, платформенная команда, работаем на скорость и качество поставки этих фич: Development Experience, пайплайны, архитектурные правила, линтеры, пресеты, дизайн-система.
Для чистоты архитектуры у нас есть несколько инструментов.
Живая база знаний с инструкциями. Это экономит часы и дни онбординга: прислал ссылку — и человек не дёргает коллег по пустякам. Косяки случаются, но мы над этим работаем.
Дизайн-документы. Если кто-то предлагает новую техническую фичу, он пишет текстом: зачем это нужно, какие альтернативы рассматривались, как будем поддерживать, как это повлияет на пользователей и на команды.
Док проходит ревью, и разработчики его либо принимают, либо отклоняют и отправляют создателя подумать ещё. Часто уже на этапе письма автор видит тонкие места, которые в голове были незаметны. Лайфхак: сначала пропишите свою гениальную идею на бумаге — возможно, вы вообще передумаете её презентовать.
Код-стайл. Автоматизируем всё что можно. У нас есть подход: если новое правило нельзя проверить и применить автоматически, велика вероятность, что оно не будет работать в реальности. Значит, мимо. В общем, стараемся использовать готовые пресеты, линтеры и codegen.
Например, для контроля зависимостей в архитектуре используем eslint-plugin-boundaries, а для проверки кода — @typescript-eslint/recommended.
А ещё у нас есть Storybook. В нём мы делаем всё то же, что и остальные, плюс нашли бонусную фичу для тестирования. Например, если крестик у модалки не работает в продукте, тестировщик открывает компонент в Storybook, быстро понимает, что это (баг UI-Kit или продуктовой логики), и относит его туда, куда нужно. Минимизируем пин-понг, где QA отсылают то в один отдел, то в другой.
А теперь о том, что у нас по легаси.
Frontend: Redux → React Query + Jotai
У нас был тяжёлый, неповоротливый Redux с кучей мидлвар и пугающими редьюсерами. При архитектуре feature-sliced, а у нас именно такая, он только мешал. Мы понимали, что масштабировать его дороже и больнее, чем постепенно убрать.
Теперь работаем на React Query для кеша и серверного состояния, а также на Jotai — для атомарных сторов. Получилось гибко, удобно и понятно. Но признаюсь, легаси-куски на Redux ещё кое-где остались. Пока что собираемся с силами, чтобы заглянуть в эти тёмные переулки.
Веб-платформа: кастом → Next.js
Когда я пришёл, у нас был фронтовый «монолит»: фронт и бэк рядом на Node, свой SSR, свой роутинг. Всё это очень долго собиралось и очень долго релизилось.
Мы пытались не трогать базу, а просто прикручивали фичи поверх, но быстро поняли: лучше не надо. В итоге решили перейти на Next.js, а бэкенд увести в отдельные микросервисы на Node.js.
По части фронтенда я сделал дизайн-док: расписал минусы, боли, влияние на скорость релизов и поддержку. Говорил на языке денег: не «было бы славно», а «станет быстрее и дешевле». Уговорить бизнес получилось, но не с первого раза.
Но это красивые истории, где мы двигались осознанно. А есть история как раз о том, как не надо.
Пару лет назад писали новое клиентское приложение. Пилили фичи, а тесты оставили на потом. По итогу, когда отдали в QA, на нас обрушились около 200 багов — от функциональных до перформанса.
Бизнес был недоволен, сроки выросли втрое, да и разработчиков это сильно демотивировало. Несколько спринтов потратили только на багфикс. Зато усвоили урок: расширили отдел QA и закрепили за каждой продуктовой зоной своего тестировщика. Больше не экспериментируем с пайплайном.
В общем, стараемся учиться на своих ошибках и думать на пару шагов вперёд.
Хочу подытожить историей моего приятеля, ML-инженера из одной шведской компании.
На одном из проектов ему достался веб-сервис на Haskell, ещё до появления LLM. Код сложный — про алгоритмы вычислительной химии. Актуальной документации не было, и спросить не у кого: все старички ушли.
В итоге ему пришлось въезжать в код с нуля и пошагово разбираться в языке. В общем, ситуация показательная: сразу понимаешь, как делать не надо. С тех пор он расписывает задачи, пишет доки и никогда не предлагает в прод что-то супернестандартное, если не знает, кто будет этим владеть и кто будет это поддерживать через год.
Мы поступаем так же. Это скучно звучит, но отлично работает.
Вместо вывода
Легаси — это нормально. Это показатель того, что ваш продукт прожил достаточно, чтобы обзавестись историей. А чтобы код при этом не превратился в болото, следите за:
Скоростью и удобством разработки — CI/CD, выбор инструментов.
Time to market — как быстро фича превращается из идеи в релиз.
Темпом онбординга и фидбэком от новых сотрудников по документации и кодстайлу.
Спасибо, что дочитали. Если у вас есть свои истории о том, как вы балансировали между скоростью и архитектурой, поделитесь в комментариях.
А я в ближайшее время планирую написать подробнее о том, как мы переезжали на RN. Думаю, будет интересно :-)