Переписывать проект с нуля или допиливать: как я принимаю решение
Почти в каждом живом проекте в какой-то момент звучит фраза: «Тут всё криво, давайте уже перепишем нормально». Формально это звучит логично, но переписать с нуля — почти всегда самый дорогой и рискованный вариант.
Когда вообще встаёт вопрос «переписать»
Сигналы обычно одни и те же: любое изменение тянет за собой баги в неожиданных местах, никто толком не понимает, как связаны модули, стек устарел так, что нормальных разработчиков на него не найти, а производительность держится на костылях. В этот момент бизнесу кажется, что проще «выкинуть и сделать по-людски», а разработчики уже устали чинить легаси.
Но сам факт того, что код старый и местами уродливый, ещё не повод переписывать. Важно понять, страдает ли от этого бизнес: теряются ли заявки, падает ли скорость разработки, мешает ли это реализовать ближайшие цели.
Плюсы и минусы допиливания
Продолжать развивать текущую систему почти всегда дешевле в краткосрок. Плюсы понятные: код уже работает в проде, есть реальные данные, проверенные сценарии, интеграции. Можно точечно усиливать слабые места: переписать критичные модули, навести порядок в архитектуре, улучшить производительность.
Минусы — накопленный техдолг: местами придётся жить с неидеальными решениями, добавлять слой адаптеров, мириться с странностями БД или структуры. Скорость разработки ограничена тем, насколько аккуратно получится раскладывать легаси, а не ломать его с размаху.
Плюсы и минусы переписывания с нуля
Переписать всё «как надо» соблазнительно: новый стек, чистая архитектура, никаких старых костылей, всё под контролем. Это реально даёт шанс сделать систему более поддерживаемой и открыть дорогу к тем фичам, которые на старом фундаменте не вытягиваются вообще.
Но у этого есть цена. Переписывание почти всегда занимает существенно больше времени, чем кажется на старте. Старые сценарии перенести один-в-один не получится, часть будет заново придумываться и теряться в процессе. Пока новый проект не вышел в прод, бизнес живёт на старом, со всеми его проблемами. А после релиза добавляется период, когда баги ловятся в бою и фактически приходится поддерживать два мира одновременно.
Как я принимаю решение на практике
Я мысленно задаю себе несколько вопросов.
Можно ли локализовать боль? Если основные проблемы в одном модуле, я склоняюсь к частичной переписке: вырезать этот кусок, сделать новый API, обернуть адаптером и встроить в существующую систему.
Есть ли жёсткий дедлайн по фичам? Если бизнесу через три месяца нужен конкретный функционал, а переписка займёт полгода, ответ очевиден: сначала закрываем цель на старом базе с разумным количеством костылей, потом планируем плавную миграцию.
Есть ли бюджет и терпение у бизнеса пережить «долгий путь»? Переписывание — это инвестиция. Если заказчик мыслит категориями «вот сейчас заплатим и через месяц всё заживёт», лучше даже не начинать.
Как я об**ъясняю это клиенту
Я не г**оворю «давайте перепишем, потому что мне неприятно смотреть на этот код». Я перевожу в язык рисков и денег: сколько будет стоить продолжать чинить текущую систему, где предел этих доработок, какие сценарии недостижимы без серьёзных изменений. И отдельно — сколько примерно займёт и будет стоить переписать всё или крупные части.
Часто оказывается, что гибридный путь самый разумный: оставить старое ядро там, где оно справляется, и постепенно выносить новые модули на свежий стек, строя мост между системами. Это не так красиво, как «переписал и забыл», зато работает и по деньгам, и по срокам.
ИтогРешение «допиливать или переписывать» — это не выбор между «красивым кодом» и «страдальческим легаси». Это баланс между рисками, задачами бизнеса и реальными ресурсами. Если смотреть на проект не только глазами разработчика, но и глазами владельца продукта, почти всегда находится вариант, который даёт максимум пользы при минимальном количестве приключений.
