Команда просит переписать продукт с нуля. Почему я почти всегда отговариваю [разбор]
Если вашему продукту больше пары лет, рано или поздно инженеры приходят с одинаковым предложением: "Код - помойка, двигаться невозможно, давайте перепишем. Дайте 9 месяцев". Иногда это правда. Чаще - нет. И дело не в том, что команда слабая.
Я несколько лет наблюдал, чем заканчивается переписывание, и хочу разобрать, почему оно проваливается даже там, где для него созданы идеальные условия - и что чинить вместо него.
Компания, построенная вокруг переписываний
Я работал в компании, которая скупала старые продукты и пыталась их переписывать. Это был не один проект, а конвейер экспериментов. Условия - мечта: сильные инженеры, выстроенные процессы, деньги, жёсткие сроки. Всё, что обычно называют причинами провала, здесь было закрыто заранее.
Сам этот код я не писал - я общался с менеджерами, которые вели переписывания. И видел один и тот же сценарий.
Нанимают команду под лозунгом "сейчас перепишем, кода будет меньше". Срок - несколько месяцев. Проваливают. Ещё раз - снова провал. Команду меняют, приходит новый менеджмент, начинают переписывать иначе. На одном продукте через меня прошло три-четыре команды. Сроки сдвигались каждый раз. Люди понимали, что рискуют работой, и всё равно не вывозили. Дольше всех держались не те, кто доводил до релиза, а те, кто умел дольше усидеть на стуле. Прошли годы - продукт, который должны были запустить, так и не запустили.
Почему не вывозят даже сильные команды
Переписать продукт с многолетней историей - это не "набрать те же фичи заново". В старом коде спрятано то, чего уже никто не помнит: пограничные случаи, поведение под конкретных клиентов, решения, которые приняли давно и нигде не записали.
На старте этого не видно. Оно всплывает, когда новая версия ломается на реальном клиенте. И таких сюрпризов столько, что оценки разлетаются в несколько раз. Команда честно оценила тот объём, который видела. Беда в том, что видела она верхушку.
"Надо переписать" - это почти всегда не про код
Вот главная мысль. "Код мешает нам двигаться быстро" - чаще всего неверный диагноз. Медленно вы двигаетесь не из-за кода, а из-за того, что вокруг него:
- ничего не автоматизировано, поэтому каждый релиз - ручная церемония;
- нет инженерных практик, поэтому любое изменение рискует уронить прод;
- инженерия и бизнес не разговаривают, поэтому половина работы делается дважды.
Переписывание не чинит ни один из этих пунктов. Вы получаете тот же сломанный процесс, только теперь поверх кода, который ещё не работает.
Что я сделал вместо переписывания
В одном проекте мне достался продукт, которому было 10 лет. Медленный, с кучей багов, релизы раз в 90+ дней. Очевидный кандидат на "снести и переписать".
Мы не переписали ни строчки. Привели в порядок процесс релизов, добавили DevOps и инженерные практики, выстроили работу вокруг существующего кода. Релизный цикл сократился с 90 дней до 1. Продукт ожил, и для него открылись рынки, которые для legacy были закрыты.
Проблема была не в идее и не в коде. Проблема была во всём, что вокруг.
Что упускают почти все: написание кода - маленькая часть
Спросите инженера, сколько времени уходит на собственно написание кода фичи. А потом - сколько проходит от момента "взяли в работу" до момента "клиент это видит".
Между этими двумя числами - пропасть. Даже в плохом коде набрать саму фичу - это малая доля пути. Остальное живёт после кода: ревью, QA, стейджинг, согласования, выкатка.
Переписывание ускоряет только один шаг - и обычно самый короткий.
Что сделать перед тем, как одобрять бюджет
Не подписывайте 9 месяцев на переписывание вслепую. Сначала попросите команду нарисовать путь фичи от идеи до продакшна: каждый шаг и сколько он занимает.
Когда вы увидите, какой процент этого пути - реально написание кода, разговор о переписывании, скорее всего, закроется сам. Узкое место окажется совсем не там, где предлагали копать.
А у вас в последний раз "надо переписать" чем оказалось на самом деле?