Дорабатывать
Проект запускается, ошибка воспроизводится, зависимости ещё поддерживаются, а нужное изменение локально и не ломает модель данных или ключевые интерфейсы.
ДОРАБОТКА · LEGACY · RELEASE · РАЗБОР
Дорабатывать или переписывать: сначала измерьте цену следующего изменения.
Старый код сам по себе не является причиной начинать заново. И наоборот, бесконечные локальные исправления могут стать дороже переноса действительно нужной логики. Решение принимается после диагностики конкретного сценария, а не по возрасту проекта.
01 / ВАРИАНТЫ
Выбирайте по ограничениям задачи.
Названия технологий полезны только после того, как понятны пользовательский сценарий, данные и требования к дальнейшему развитию.
Заменить часть
Один модуль, интеграция или экран создаёт большинство проблем. Его можно отделить контрактом и заменить, сохранив остальной рабочий продукт.
Переписывать
Каждая небольшая правка требует менять несвязанные участки, нет воспроизводимой сборки, зависимости критически устарели или текущая модель данных блокирует необходимый продуктовый сценарий.
Где решение начинает отличаться.
Где решение начинает отличаться.
02 / КРИТЕРИИ
Rewrite почти всегда недооценивают
В старом проекте уже зашиты десятки мелких решений: edge cases, форматы данных, права, поведение пользователей. При полном переписывании их приходится заново обнаруживать. Поэтому новая кодовая база не означает автоматически меньший риск.
Начните с одного критичного сценария
Полезнее воспроизвести конкретную проблему — например, пользователь не может оплатить или заявка не попадает в CRM — и пройти путь от интерфейса до данных. Это показывает реальные границы дефекта и качество соседних модулей лучше, чем абстрактная оценка «код плохой».
Частичная замена часто даёт лучший баланс
Если проблемный участок имеет понятные входы и выходы, его можно вынести в новый модуль или сервис. Такой подход сохраняет работающие части и одновременно снижает риск будущих изменений в самом слабом месте.
Переписывание оправдано, когда меняется сам продукт
Если новая версия требует другой модели ролей, данных и пользовательского пути, сохранение старой архитектуры может стать искусственным ограничением. Тогда задача уже не «починить код», а перенести подтверждённую бизнес-логику в новую систему.
Ориентир до технического задания.
Ориентир до технического задания.
03 / БЫСТРАЯ ПРОВЕРКА
Одна воспроизводимая ошибкаДоработать
Нестабильна одна интеграцияЗаменить часть
Нет воспроизводимой сборки и тестового окруженияСначала диагностика
Меняется только интерфейсОбычно доработать
Меняется модель данных и основной пользовательский путьРассмотреть rewrite
04 / ВОПРОСЫ
Два частых пограничных случая.
Можно ли оценить чужой код без полного аудита?
Первую задачу — часто да. Для точной оценки всего будущего развития нужен больший контекст, но воспроизводимый проблемный сценарий уже даёт полезную информацию.
Что прислать для диагностики?
Ссылку или архив проекта, способ запуска, шаги воспроизведения проблемы и ожидаемое поведение. Если есть логи или доступ к тестовой среде, они сокращают время поиска причины.
05 / ДАЛЬШЕ
Перейдите к конкретному направлению.
Если после сравнения формат понятен, коммерческая страница уже описывает состав результата, кейсы и следующий шаг.
СЛЕДУЮЩИЙ ПРОЕКТ — ВАШ
Давайте соберём
что-то сильное.
Пара предложений о задаче — уже начало. Ссылка, макет или существующий код помогут оценить объём.
@Alexuys ↗alexgtup@gmail.com