AndrewKozlov
New member
Три года назад я впервые вошёл в комнату, где сидела команда, поддерживавшая систему, которой было шестнадцать лет. Монолит на древней версии платформы, тестовое покрытие в районе десяти процентов, релизы раз в месяц по ночам, и один разработчик, который знал, почему в модуле заказов закомментирован целый блок с пометкой не трогать. Бизнес при этом рос, выручка била рекорды, и именно поэтому любой разговор о рефакторинге заканчивался одинаково: у нас нет времени, у нас нет людей, у нас всё работает.
Классический парадокс legacy: система достаточно плоха, чтобы её хотелось переписать, и достаточно хороша, чтобы это никогда не окупалось одномоментно. Я потратил первые полгода на попытки протолкнуть большой проект миграции и потерпел полное фиаско. Совет директоров справедливо спросил, что они получат через квартал, а мне было нечего ответить, кроме слова архитектура. Тогда я изменил подход и перестал продавать рефакторинг как отдельный проект.
Первое, что я сделал, — перевёл работу с техническим долгом в плоскость метрик бизнеса. Не связанность модулей, а время вывода фичи на рынок. Не покрытие тестами, а количество инцидентов на продовой среде за спринт. Не качество кода, а стоимость часа разработки при доработке конкретного домена. Когда на доске появилась кривая, показывающая, что каждая новая функция в биллинге стоит нам в три раза дороже, чем в остальных подсистемах, разговор с бизнесом стал совсем другим.
Второй принцип, который я теперь считаю главным: рефакторить только то, что трогаешь. Мы отказались от идеи вычистить весь монолит и приняли правило мальчика-скаута в строгой формулировке — заходя в модуль ради задачи, оставляем его чуть лучше, чем он был. Обязательно покрываем тестами тот участок, который меняем, обязательно выносим одну зависимость, обязательно убираем один хак. За год таких мелких шагов накопилось столько, что два самых проблемных домена перестали быть проблемными, и никто не заметил героического переписывания.
Третий элемент — стратегия отсечения. Мы выбрали несколько вертикальных срезов бизнеса, которые развиваются быстро и болезненно, и начали постепенно выводить их в отдельные сервисы за фасадом. Ключевое слово здесь постепенно: сначала новый код ходит и в монолит, и в новую логику, потом переключается трафик на процент пользователей, потом старый путь тихо умирает. Бизнес не останавливается ни на день, у нас нет большого переключателя, который однажды ночью может всё сломать. Зато есть обратимость на каждом шаге, а это то, что реально успокаивает продуктовую команду и заказчиков.
Отдельно скажу про людей, потому что это чаще всего и есть настоящий legacy. Если один инженер — единственный носитель знаний о критичном модуле, никакой рефакторинг не спасёт. Мы ввели обязательные парные сессии на самых тёмных участках, ротацию дежурств и документирование решений в виде коротких заметок прямо в репозитории. Через полгода у каждого критичного сервиса было минимум три человека, способных его поднять. Это дороже, чем кажется, но дешевле, чем отпуск, совпавший с падением продакшена.
Если вы сейчас в позиции CTO или техлида и у вас на руках такая же система, дам простой совет. Не приходите к руководству со словом рефакторинг. Приходите с двумя цифрами: сколько стоит бизнесу текущее состояние и сколько будет стоить каждый шаг улучшения. Договоритесь о постоянной небольшой доле времени команды, которую никто не отбирает под срочные задачи, и защищайте её как зарплатный фонд. Работайте маленькими шагами, оставляйте систему рабочей после каждой итерации и никогда не начинайте переписывание без возможности откатиться.
Теперь мой вопрос к вам, коллеги. Какой самый изящный приём помог вам продвинуть работу с legacy внутри компании — метрика, аргумент, эксперимент или просто удачно найденный момент? Поделитесь историей, где вы смогли улучшить сложную систему и при этом ничего не остановить, мне кажется, такие примеры вдохновляют сильнее любой методологии.
Классический парадокс legacy: система достаточно плоха, чтобы её хотелось переписать, и достаточно хороша, чтобы это никогда не окупалось одномоментно. Я потратил первые полгода на попытки протолкнуть большой проект миграции и потерпел полное фиаско. Совет директоров справедливо спросил, что они получат через квартал, а мне было нечего ответить, кроме слова архитектура. Тогда я изменил подход и перестал продавать рефакторинг как отдельный проект.
Первое, что я сделал, — перевёл работу с техническим долгом в плоскость метрик бизнеса. Не связанность модулей, а время вывода фичи на рынок. Не покрытие тестами, а количество инцидентов на продовой среде за спринт. Не качество кода, а стоимость часа разработки при доработке конкретного домена. Когда на доске появилась кривая, показывающая, что каждая новая функция в биллинге стоит нам в три раза дороже, чем в остальных подсистемах, разговор с бизнесом стал совсем другим.
Второй принцип, который я теперь считаю главным: рефакторить только то, что трогаешь. Мы отказались от идеи вычистить весь монолит и приняли правило мальчика-скаута в строгой формулировке — заходя в модуль ради задачи, оставляем его чуть лучше, чем он был. Обязательно покрываем тестами тот участок, который меняем, обязательно выносим одну зависимость, обязательно убираем один хак. За год таких мелких шагов накопилось столько, что два самых проблемных домена перестали быть проблемными, и никто не заметил героического переписывания.
Третий элемент — стратегия отсечения. Мы выбрали несколько вертикальных срезов бизнеса, которые развиваются быстро и болезненно, и начали постепенно выводить их в отдельные сервисы за фасадом. Ключевое слово здесь постепенно: сначала новый код ходит и в монолит, и в новую логику, потом переключается трафик на процент пользователей, потом старый путь тихо умирает. Бизнес не останавливается ни на день, у нас нет большого переключателя, который однажды ночью может всё сломать. Зато есть обратимость на каждом шаге, а это то, что реально успокаивает продуктовую команду и заказчиков.
Отдельно скажу про людей, потому что это чаще всего и есть настоящий legacy. Если один инженер — единственный носитель знаний о критичном модуле, никакой рефакторинг не спасёт. Мы ввели обязательные парные сессии на самых тёмных участках, ротацию дежурств и документирование решений в виде коротких заметок прямо в репозитории. Через полгода у каждого критичного сервиса было минимум три человека, способных его поднять. Это дороже, чем кажется, но дешевле, чем отпуск, совпавший с падением продакшена.
Если вы сейчас в позиции CTO или техлида и у вас на руках такая же система, дам простой совет. Не приходите к руководству со словом рефакторинг. Приходите с двумя цифрами: сколько стоит бизнесу текущее состояние и сколько будет стоить каждый шаг улучшения. Договоритесь о постоянной небольшой доле времени команды, которую никто не отбирает под срочные задачи, и защищайте её как зарплатный фонд. Работайте маленькими шагами, оставляйте систему рабочей после каждой итерации и никогда не начинайте переписывание без возможности откатиться.
Теперь мой вопрос к вам, коллеги. Какой самый изящный приём помог вам продвинуть работу с legacy внутри компании — метрика, аргумент, эксперимент или просто удачно найденный момент? Поделитесь историей, где вы смогли улучшить сложную систему и при этом ничего не остановить, мне кажется, такие примеры вдохновляют сильнее любой методологии.