Trust goal: show_process
Почему доработка чужого legacy-проекта требует другого подхода
Legacy-проект — это не обязательно плохой проект. Часто это рабочий сайт, интернет-магазин, CRM или личный кабинет, который много лет приносит заявки и заказы, но постепенно стал сложным: старые модули, нестандартные доработки, забытые интеграции, разные версии PHP, ручные правки на сервере и мало документации.
Главная ошибка при доработке такого проекта — сразу «чинить по месту». На первый взгляд задача может быть простой: добавить поле, поменять статус, поправить фильтр, ускорить страницу. Но если не понять связи внутри проекта, маленькая правка может задеть каталог, оплату, CRM, обмен с 1С, почтовые уведомления или аналитику.
Поэтому доработка чужого кода должна начинаться не с героизма, а с процесса: быстро определить границы задачи, проверить зависимости, сделать резервную копию, выбрать безопасный способ проверки и только потом менять код.
Кому это актуально
Эта статья для компаний, у которых есть действующий проект, но текущая команда уже не может быстро развивать его. Например:
- сайт на 1С-Битрикс с большим количеством нестандартных модулей;
- интернет-магазин на OpenCart или другой CMS с доработанным каталогом;
- CRM или личный кабинет на Yii, Symfony, Laravel или самописном PHP;
- Node.js API или сервис рядом с основным сайтом;
- проект без полной документации после нескольких подрядчиков.
Если нужна конкретная доработка, можно начать со страницы разовых доработок. Если задач много и они повторяются, стоит смотреть поддержку сайтов или тарифы сопровождения.
Что проверить перед первой правкой
Перед тем как менять чужой legacy-код, нужно ответить на несколько вопросов.
Есть ли резервная копия и понятно ли, как восстановиться? Если отката нет, даже простая задача становится рискованной.
Есть ли Git или другой контроль версий? Если кода в репозитории нет, стоит хотя бы зафиксировать текущую версию перед изменениями.
Где боевое окружение, а где тестовое? Если тестового контура нет, нужно согласовать аккуратную схему проверки: копия страницы, временное окно, ограниченный релиз или ручной smoke-test.
Какие сценарии считаются критичными? Для интернет-магазина это каталог, корзина, заказ, оплата, доставка и уведомления. Для B2B-сайта — формы заявок, CRM, почта, аналитика и документы. Для сервиса — авторизация, API, личный кабинет и интеграции.
Кто принимает результат? Без ответственного на стороне клиента задача может зависнуть в статусе «почти готово», а правка останется непроверенной.
Какие риски закрывает правильный процесс
Первый риск — скрытые зависимости. В старом проекте одно поле может использоваться в шаблоне, выгрузке, письме, CRM и отчёте. Если изменить его только в одном месте, часть сценариев начнёт расходиться.
Второй риск — несовместимость версий. На проекте может быть старая версия PHP, CMS, библиотеки или модуля. Новый код, который нормально работает в свежем окружении, может сломаться на боевом сервере.
Третий риск — накопленный технический долг. Иногда задача кажется дорогой не потому, что подрядчик завышает оценку, а потому что перед простой правкой нужно распутать старую архитектуру. Честный подрядчик должен объяснить, где цена связана с риском, а где действительно можно сделать быстро.
Четвёртый риск — отсутствие проверки после релиза. Доработка считается законченной не когда код загружен на сервер, а когда проверены затронутые сценарии: форма отправляет данные, заказ создаётся, письмо уходит, CRM получает событие, страница не стала медленнее.
Как это решает OpenStart
OpenStart часто работает не с новыми проектами с чистого листа, а с действующими сайтами и сервисами, где уже есть история решений. Поэтому подход строится вокруг аккуратного входа в проект и постепенного снижения риска.
Команда сначала определяет границы задачи: что нужно изменить, какие страницы и интеграции затронуты, какие данные нужны для проверки. Затем выбирается способ работы: Git, копия, тестовый контур, ограниченный релиз или ручное согласованное окно. После доработки проверяется не только изменённый экран, но и связанные сценарии.
Для проектов на 1С-Битрикс можно отдельно посмотреть направление Bitrix, потому что там часто важны кеширование, обмены, права, компоненты и модули. Для серверной логики, API и интеграций подходит направление Node.js. Для задач продаж и внутренних процессов — CRM. Если проект тормозит или проседает по Core Web Vitals, полезна диагностика скорости и технических ограничений.
Что запросить у подрядчика
Перед доработкой legacy-проекта спросите подрядчика не только «сколько стоит», но и «как вы будете снижать риск».
- Какие файлы, таблицы, модули и интеграции могут быть затронуты.
- Как будет сделан откат, если правка поведёт себя не так.
- Где будет проверяться задача до выкладки.
- Какие сценарии войдут в smoke-test после релиза.
- Что будет зафиксировано в PM-системе или отчёте.
- Какие части проекта лучше не трогать без отдельного аудита.
- Нужно ли сначала привести в порядок Git, резервные копии или окружение.
Такие вопросы помогают отличить разработчика, который «сейчас быстро поправит», от команды, которая берёт ответственность за рабочий проект.
FAQ
Всегда ли legacy-проект нужно переписывать?
Нет. Часто выгоднее постепенно стабилизировать проект, закрыть критичные риски и развивать нужные бизнес-функции. Переписывание оправдано только после анализа стоимости, рисков и ожидаемого эффекта.
Почему оценка доработки может измениться после аудита?
Потому что до просмотра кода подрядчик видит только внешнюю задачу. После аудита могут обнаружиться зависимости, старые модули, нестандартные интеграции или отсутствие безопасного способа проверки.
Можно ли дорабатывать проект без документации?
Можно, но нужно закладывать время на исследование. Документацию можно постепенно восстановить в процессе: фиксировать ключевые сценарии, окружение, интеграции и правила релиза.
Что важнее: скорость или безопасность правки?
Для аварии важна скорость реакции, но даже срочная правка должна иметь минимальную проверку и план отката. Для плановых задач лучше не жертвовать безопасностью ради нескольких часов.
Для редактора
Клиентские имена, внутренние задачи, домены, неподтверждённые цифры, награды и отзывы не использовались. Перед публикацией стоит проверить, что формулировки не обещают гарантированный результат и совпадают с текущим позиционированием OpenStart по поддержке и доработке рабочих проектов.
Связанные маркетинговые задачи
- Название: подготовить чек-лист доработки legacy-проекта; stream: sales_materials; priority: high; next_action: собрать вопросы про Git, резервные копии, тестовый контур и smoke-test.
- Название: добавить на `/improvement` блок про безопасную работу с чужим кодом; stream: website_trust; priority: high; next_action: проверить текущую страницу и предложить компактный блок без увеличения первого экрана.
- Название: выбрать анонимизированный кейс по доработке проекта без документации; stream: cases; priority: medium; next_action: согласовать, какие детали можно раскрывать без клиента и домена.
- Название: подготовить внешний пост о том, почему legacy не всегда нужно переписывать; stream: media; priority: low; next_action: сделать нейтральный технический разбор без рекламы.