Rewrite или probe: как не сжечь бюджет на модернизации Bitrix

Когда на зрелом e-commerce проекте снова всплывает фраза «давайте перепишем все», я обычно прошу остановиться на один шаг раньше. Не потому что rewrite всегда плохой. Плохой rewrite — это когда команда еще не понимает, где именно теряются деньги, скорость и управляемость.

Что я проверяю до большого решения

В первые дни важнее не выбрать стек, а отделить симптомы от причины. Каталог может тормозить из-за SQL-запросов, фасетов, кэша, тяжелого фронтенда, интеграции с 1C или просто из-за того, что никто давно не смотрел на реальные метрики. Если сразу начать переписывать интерфейс, можно красиво перенести старую проблему в новый Next.js.

Хороший probe отвечает на практичные вопросы: какие страницы дают выручку и SEO-трафик, где ломается Core Web Vitals, какие API нужны фронтенду, какие роли и workflows нельзя упростить, какие интеграции нельзя трогать без rollback-плана.

Как выглядит полезный малый шаг

• Берем один ограниченный участок: категорию, поиск, фильтры, карточку товара или критичный пользовательский сценарий.
• Фиксируем baseline: скорость, индексация, ошибки, логи, конверсионные точки, ограничения Bitrix/PHP-ядра.
• Описываем базовый scope отдельно от optional/client-specific функциональности.
• Договариваемся о критериях приемки: что должно стать быстрее, понятнее или безопаснее для релиза.
• Только после этого оцениваем следующий этап с учетом данных, интеграций, ролей и workflows.

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

Почему это важно founder или CTO

Большой rewrite почти всегда продается как освобождение от legacy. На практике он добавляет новый риск: команда получает второй контур разработки, миграцию данных, SEO-переезд, новые deployment-процессы и больше мест, где можно потерять контроль. Probe делает разговор предметным: не «переписываем или нет», а «какой кусок снижает риск и дает измеримый результат первым».

Для личной работы я использую тот же принцип: сначала карта рисков и компактный scope, потом архитектурное решение. Если задача уже ближе к e-commerce modernization, я подключаю командный контур WGP: можно начать с короткого audit/probe запроса и показать реальный каталог, а не абстрактную задачу.

В нормальном проекте цена не должна появляться раньше понимания scope. Сначала предварительные требования, базовое против optional, интеграции, данные, роли, workflows и acceptance criteria. Потом уже оценка, команда и план релиза.