Rewrite fever: почему legacy e-commerce лучше модернизировать слоями
Самый опасный момент в legacy e-commerce - когда команда уже устала, а кто-то на встрече говорит: “давайте просто перепишем все с нуля”.
Звучит логично. Старый Bitrix или Laravel мешает релизам. Фильтры медленные. Каталог растет. SEO-страницы завязаны на странные шаблоны. Разработчики боятся трогать checkout перед пиковым сезоном.
Но полный rewrite часто не лечит проблему. Он просто переносит риск в новое место.
Что я проверяю до решения о rewrite
Я обычно начинаю не со стека, а с карты риска:
- какие страницы реально приносят деньги;
- где каталог, поиск или фильтры ломают конверсию;
- какие интеграции нельзя остановить даже на день;
- что можно вынести отдельно без миграции всей системы;
- какие метрики покажут, что изменение сработало.
После этого rewrite часто превращается в staged modernization. Не “снести дом и построить новый”, а вынести первый слой, который уже тормозит бизнес.
Типичный первый слой
Для e-commerce это часто каталог, поиск или фронтенд промо-страниц.
Например: оставить рабочий backend, но вынести storefront на Next.js, добавить нормальный search layer на Elasticsearch, договориться об API-контракте и сделать rollout по ограниченному набору категорий. Если что-то идет не так - есть rollback. Если все хорошо - расширяем зону.
Такой подход скучнее, чем большой rewrite. Зато он лучше отвечает на главный вопрос владельца: “как улучшить сайт и не остановить продажи?”
Где здесь AI
AI помогает быстрее собирать адаптеры, тестовые сценарии, документацию, внутренние инструменты и рутинный код. Но он не заменяет решение о границах системы.
Граница - это инженерная работа. Что оставить. Что вынести. Где поставить наблюдаемость. Как проверить, что изменение не убило SEO, заказы и работу контент-команды.
Практичный следующий шаг
Если вы смотрите на legacy Bitrix/Laravel и не понимаете, нужен ли rewrite, я бы не начинал с большого ТЗ.
Я бы начал с компактного discovery:
- реальный каталог или критичный user flow;
- текущие bottlenecks и бизнес-риски;
- base scope отдельно от optional/client-specific вещей;
- один ограниченный work slice, который можно измерить.
Для WGP это часто формат Catalog Probe: взять реальный каталог, проверить search/frontend гипотезу и понять, есть ли смысл идти дальше.
Без магии. Без обещания фиксированной цены на неизвестный проект. Сначала scope, integrations, data, roles, workflows и acceptance criteria. Потом оценка.
I don’t burn down legacy. I modernize it.