Что считать подхватом, а что — переписыванием
Подхват — это работа с продуктом, в котором уже есть пользователи, данные, интеграции и операционные процессы. Команда не «начинает заново», а возвращает управляемость: разбирается, что устроено в коде, кто владеет аккаунтами, как выходят релизы, где живут риски.
Переписывание с нуля — это новый проект с теми же продуктовыми целями, но без оглядки на текущий код. Старая система или продолжает работать на время миграции, или замораживается, или сворачивается. На каждом из этих сценариев свой набор рисков, и часто их недооценивают на старте.
Между этими крайностями есть промежуточные варианты: подхватить целиком, но точечно переписать опасные модули; подхватить часть, передать другую новой команде; временно стабилизировать систему и переписать её через несколько месяцев. Решение редко бывает бинарным.
Заметка
Если разговор начинается со слов «давайте просто перепишем», это почти всегда сигнал эмоционального, а не аналитического решения. На этом этапе полезно остановиться и явно сформулировать, что именно мешает работать с текущей системой.
Когда подхват разумнее
На практике подхват чаще оказывается менее рискованным путём, чем кажется в первые дни работы с чужим кодом. Несколько типичных условий, при которых он почти всегда оправдан:
- у продукта уже есть пользователи, оплаты или интеграции, и их нельзя поставить на паузу;
- архитектура в целом адекватна задаче, а проблемы носят локальный характер;
- основная боль — операционная: непредсказуемые релизы, отсутствующие доступы, ручные обходы вместо процесса;
- команда умеет читать чужой код и не боится разбирать продакшен;
- бизнес не готов финансировать длительный rewrite без видимых результатов в первые месяцы.
Подхват сохраняет данные и не требует параллельной поддержки двух систем. Часть критики чужого кода исчезает после нескольких недель работы с ним: становится видно, что многие странные решения были вынужденными, а не плохими.
Когда честнее переписать
В отдельных случаях переписывание — действительно разумнее. Признаки, при которых стоит рассматривать такой вариант:
- стек больше не поддерживается и обновить его невозможно без эффективного переписывания;
- ключевая часть бизнес-логики оказывается несовместимой с реальной моделью данных, а обходы становятся новой моделью;
- правовая ситуация не позволяет использовать существующий код, например при неопределённых правах;
- поддержка системы обходится дороже, чем разработка нового кода с тем же функционалом;
- безопасность нарушена настолько, что отдельные правки не дают устойчивого результата.
Заметная часть случаев, в которых «надо переписать», на самом деле звучит как «давайте не разбираться с чужим кодом». Перед решением имеет смысл явно сформулировать, какие именно ограничения нынешней системы непреодолимы.
Риск
Параллельная поддержка старой и новой системы почти всегда длится дольше, чем планируется. В этот период любая новая фича стоит ощутимо дороже, потому что её приходится делать дважды.
Что проверить перед решением
Любое сравнение «подхват vs rewrite» строится на ощущениях, пока не пройден короткий контрольный список. Эти разделы образуют рабочую базу для аудита перед подхватом:
- состояние кода — насколько он читается, как часто что-то ломается после релизов;
- состояние инфраструктуры — есть ли воспроизводимая сборка, кто владеет аккаунтами, как работают бэкапы;
- состояние данных — какие сущности живы, где источник правды, какие правила миграции реальны;
- зависимости и интеграции — что сломается при переключении, какие контракты с внешними системами устарели;
- команда и контекст — кто сможет ответить на вопросы по архитектуре, как формализованы регламенты.
Типовые ошибки в обе стороны
Со стороны подхвата
Самая частая ошибка — взять весь проект, не зафиксировав границы. Через несколько недель команда обнаруживает, что чинит не только то, что обещала, но и смежные модули, которые «всё равно сломаются». Бюджет уходит на поддержание, новых функций нет, заказчик недоволен. Защита от этой ошибки — явный периметр подхвата на старте и договорённость о том, что попадает за его рамки.
Со стороны переписывания
Чаще всего недооценивают объём дублирования. Новая система долго догоняет старую по функциональности, а параллельно нужно поддерживать обе. Заказчик платит дважды, и в этот период любая новая фича стоит ощутимо дороже. Защита — пошаговая миграция функциями, а не «два года пишем новое, потом переключаемся».
Ни один из этих сценариев нельзя предсказать на этапе «решаем, что делать». Их можно только удержать в поле зрения, чтобы вовремя поймать.
Сравнение по ключевым осям
Удобно держать перед глазами короткое сравнение двух подходов по тем осям, на которых обычно ломается решение:
| Ось | Подхват | Переписывание |
|---|---|---|
| Активные пользователи | Продолжают работать без переключения | Нужен план миграции и окно простоя |
| Данные и история | Сохраняются как есть | Требуют отдельной миграции |
| Время до первого эффекта | Обычно недели | Обычно месяцы |
| Видимость прогресса | Релизы небольшими шагами | Долго невидимая работа, потом разовая выкатка |
| Стек и архитектура | Наследуются с компромиссами | Выбираются заново |
| Юридический риск | Требует прав на код | Может обойти спорный код |
Как принимать решение по модулям
Самый устойчивый подход — рассматривать систему по слоям и принимать решение отдельно для каждого. Один и тот же продукт может содержать модуль, который имеет смысл подхватить целиком, и модуль, который проще переписать как отдельный сервис.
Для каждого модуля стоит ответить на короткий набор вопросов:
- насколько модуль изолирован от остального кода;
- сколько данных в нём;
- какие интеграции на нём завязаны;
- насколько прозрачна его бизнес-логика;
- есть ли владелец процесса на стороне заказчика.
Decision matrix
Грубая таблица для первичной оценки. Конкретное решение всегда требует разговора с владельцем продукта и взгляда в код.
| Признак модуля | Подхват | Переписать | Гибрид |
|---|---|---|---|
| Активные пользователи и данные | да | — | да |
| Архитектура устарела | — | да | да |
| Модуль изолирован | да | да | да |
| Мало времени до результата | да | — | отчасти |
| Спорная юридическая часть | — | да | отчасти |
Когда подключать аудит
Аудит перед подхватом — отдельный формат работы. Его задача не «оценить уровень кода», а собрать факты, которые позволят выбрать формат дальнейшей работы: подхват, частичное переписывание, новый продукт. После аудита решение перестаёт быть субъективным.
В аудите имеет смысл проходить по перечисленным выше пунктам, фиксировать риски, выдавать рекомендации и сразу обсуждать сценарии следующего шага. Если аудит заканчивается выводом «лучше переписать», это тоже нормальный результат: важнее, что решение принимается с цифрами и аргументами, а не по эмоциям.
Если коротко
Подхват и переписывание — не противоположности, а полярности шкалы. На большинстве реальных проектов оптимальное решение лежит где-то посередине: стабилизировать целиком, переписать выборочно, иногда — выделить опасные модули и заменить их новыми сервисами. Чтобы выбрать точку на этой шкале, нужно начать с фактов, а не с впечатлений.
Если это похоже на вашу ситуацию
Начните с короткого разбора: что уже есть, какие доступы нужны и где риски перед сменой подрядчика.