Есть одна фраза, которую я слышал в десятках проектов.
Она звучит почти невинно, даже логично:
"Сейчас сделаем как получится, а потом перепишем".
Это как обещание себе "начну бегать с понедельника" — звучит приятно, но заканчивается одинаково.
Спойлер: почти никто не переписывает.
Хочу рассказать историю, почему так происходит и чем заканчивается.
История стартапа, который "успеет переписать"
Три года назад ко мне пришёл стартап с идеей, от которой у инвесторов горели глаза. Продукт решал реальную боль, рынок огромный, первые деньги уже на руках.
Команда — небольшая, 5 разработчиков, CTO из друзей основателя, сеньор-джуниор (да да, тот самый). Сроки — горят.
И на первом созвоне я услышал знакомое:
Слушай, нам нужно просто выйти. Код не важен.
Сейчас соберём MVP на коленке, а когда будут пользователи и деньги — перепишем нормально.
Звучит разумно, правда? Убедительно.
Запускаем быстрее -> тестируем гипотезу -> получаем инвестиции -> строим всё по уму.
Я попробовал тогда оспорить, но это был разговор со стеной... убеждать бесполезно, пока боль не случилась.
Первая победа (и начало проблем)
Через два месяца продукт запустили. Да, на соплях.
Стек: то, что было под рукой, архитектура — "лишь бы работало".
И как обычно, дуракам и пьяницам... Короче, они выстрелили.
Первые клиенты пришли, инвесторы довольны, цифры растут.
Команда в эйфории.
И вот тут должна была прозвучать фраза:
Окей, ребята, пора переписать.
Но вместо этого я услышал:
Нужны новые фичи.
Конкуренты сделали интеграцию с X — нам тоже надо.
И понеслось!
Как код превращается в мину замедленного действия
Через полгода я снова заглянул в проект.
Кодовая база выросла в 5 раз.
Автотестов — ноль.
CI/CD? - зачем, Валера филигранно катит с ноута руками.
Документация? - тоже у Валерки в голове.
В багтрекере висело 100-200+ тикетов.
Скорость фичей падала, баги множились, релизы стали стрессом.
И самое интересное — команда уже не могла переписать продукт.
Причины просты:
Цена переписывания выросла в десятки раз. У них тысячи пользователей, десятки интеграций, SLA.
Нет времени, рынок давит, конкуренты не ждут, инвесторы требуют роста.
Нет смелости или понятных аргументов. Как объяснить инвестору: "Мы остановим разработку на 4 месяца, чтобы сделать то же самое, но правильно"?
Они пытались тянуть на старой базе ещё год.
А потом начали терять клиентов.
Каждая новая фича занимала в 3 раза больше времени, чем планировалось. Баги в проде стали нормой.
Финал предсказуем: проект просто слили за копейки.
Почему "потом перепишем" — миф
Вот три причины, почему переписывание почти не случается:
Рост пожирает ресурсы
Каждый день появляются новые фичи, баги, клиенты, партнёры. В этой гонке "переписать" всегда внизу приоритетов.Цена растёт экспоненциально
В первый месяц переписать код можно за неделю. Через год — за полгода (и то, неуверенно).Психология бизнеса
Фраза "мы заморозим развитие ради переписывания" убивает переговоры с инвесторами или начальством.
Почему MVP != "сделать на коленке"
Сразу уточню: я не против MVP.
Я против хаоса под видом MVP.
Проблема не в том, что вы делаете быстро, а в том, что вы делаете без понимания, как это будет жить завтра.
Есть разница между:
MVP, спроектированным так, чтобы выдержать 2–3 итерации роста
и MVP на соплях, который развалится при первой нагрузке
Первое — гибкость.
Второе — технический долг, который сожрёт вас.
Что делать вместо "потом перепишем"
1. Думайте наперёд, но без фанатизма
Вам не нужен монолит размером с Enterprise, но и «файл на 10 000 строк» — плохая идея.
Сделайте архитектуру такой, чтобы её можно было расширять без боли.
Представьте, что вы Шерлок Холмс: предугадываете пару ходов вперёд, а не строите план на 10 лет.
2. Инфраструктура — не роскошь
Автотесты, CI/CD, нормальное логирование.
Не для красоты, а чтобы завтра не ловить баги в проде в три часа ночи.
Запомните простую математику: час на тесты сегодня = неделя экономии завтра.
3. Технический долг — это кредит под дикий процент
Его нельзя игнорировать.
Договоритесь в команде: как только долг выходит за лимит — ставим фичи на паузу, идём чистить.
Неприятно? Да!
Но дешевле, чем потом переписывать всё с нуля или терять продукт.
Итог
Фраза "мы потом перепишем" звучит безобидно.
Но в реальности это ловушка, из которой почти никто не выбирается.
Если вы слышите её на мите — задайте три вопроса:
Когда именно?
Кто это сделает?
За чей счёт?
Если честного ответа нет — поздравляю, вы строите небоскрёб на песке.
Оффтоп
В Telegram-канале Техдир на пальцах я также разбираю подобные проблемы/кейсы/советы. Там все про разработку и управление, но простым языком, понятным бизнесу.