Почему я не начинаю legacy-проект с переписывания

July 21, 2026

Когда мне показывают старый Bitrix, Laravel или самописный PHP-проект, первый импульс у бизнеса часто понятен: переписать на нормальный стек и забыть.

Я обычно начинаю не с этого. Старый код может раздражать команду, но он часто уже держит каталог, заказы, SEO, интеграции, роли, привычки менеджеров и деньги. Если сразу назвать rewrite главным решением, легко переписать не проблему, а симптом.

Сначала карта риска

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

Обычно быстро всплывают разные типы риска:

catalog/search: фильтры, фасеты, остатки, скорость, релевантность;
integrations: 1C, CRM, оплаты, доставка, внешние API;
release process: нет staging, rollback, понятной проверки после деплоя;
ownership: один человек знает критический кусок, документации нет;
SEO/content: исторические URL, редиректы, метаданные, редакторские сценарии.

После такой карты становится видно, что именно надо лечить. Иногда это действительно Next.js-фронт и отдельный search-контур. Иногда достаточно изолировать один API adapter, почистить кеш-слой, стабилизировать деплой и перестать трогать ядро без тестов.

Rewrite редко бывает одной задачей

Фраза "переписать сайт" звучит как один проект. Внутри это пачка разных решений.

Что остается в старой системе? Что переносится? Кто владеет API-контрактом? Где граница между базовым запуском и optional-функциями? Какие потоки должны пройти приемку без ручной магии?

Если эти вопросы не заданы, fixed price на custom rewrite превращается в гадание. Либо подрядчик закладывает огромный буфер, либо клиент получает конфликт по каждому нормальному уточнению scope.

Я предпочитаю другой порядок: короткая диагностика, компактная структура требований, разделение base/optional, затем оценка по milestone или рабочему slice.

Тестовый slice честнее большой презентации

Для legacy e-commerce хороший первый slice часто выглядит очень приземленно:

Одна категория с тяжелыми фильтрами.
Один search-flow с понятной метрикой качества.
Один API adapter между Bitrix/Laravel и новым фронтом.
Один участок Core Web Vitals с замером до/после.
Один релиз через staging, review, rollback-plan и production check.

Такой slice показывает больше, чем презентация на 40 слайдов. Видно, как команда получает доступы, читает старый код, документирует решения, объясняет компромиссы и проверяет результат.

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

Где здесь роль senior-инженера

В legacy-проектах ценность senior-инженера не в том, чтобы первым сказать "надо переписать". Это может сказать кто угодно.

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

В моем опыте headless, Next.js и Elasticsearch работают хорошо, когда у них есть причина. Например, когда catalog/search реально тормозит продажи, маркетинг не может выпускать страницы без разработчиков, или старый frontend мешает релизам. Но если главная проблема в процессе, данных или ownership, новый стек сам по себе не спасает.

С чего начать

Если вы смотрите на legacy-проект и думаете о rewrite, я бы начал с трех документов:

карта рисков: что нельзя сломать и где уже больно;
короткий functional scope: base, optional, integrations, acceptance criteria;
первый test slice: один ограниченный участок, который проверяет не только код, но и workflow.

Для коммерческого проекта WGP может оформить это как technical audit / Catalog Probe. Если нужен прямой разговор со мной как с инженером, лучше написать в Telegram или LinkedIn.