За свою карьеру я участвовал в переписывании, наверное, десятка систем, которые принято называть словом legacy. И почти каждый раз сценарий повторялся: кто-то из коллег закатывал глаза и говорил, что этот код надо сжечь и написать заново. А потом приходил финансовый директор и напоминал, что именно этот «ужасный» код приносит компании треть выручки. Именно об этом противоречии хочется поговорить честно, без манифестов и модных терминов ради терминов.
Расскажу про свой самый показательный проект. Онлайн-запись и приём платежей для сети клиник: монолит на старом PHP, jQuery, MySQL без единого внешнего ключа, миграции руками, а деплой через FTP по пятницам. Писал всё это один человек, который уволился четыре года назад и оставил после себя документацию в виде трёх сообщений в корпоративном чате. При этом система стабильно обслуживала десятки тысяч записей в месяц, и никто в бизнесе не хотел слышать слово «остановка», даже на техническое окно в одну ночь.
Первая наша попытка была классической ошибкой. Мы выбили бюджет, собрали команду из шести человек и год с лишним писали «правильную» систему на современном стеке. Бизнес за это время пять раз поменял требования, мы отставали от графика, а на демо получали вежливое «а где привычные отчёты и интеграция с лабораторией». В итоге вместо запуска мы получили выгоревшую команду и сильно подорванное доверие заказчика. С тех пор я настороженно отношусь к проектам, где слово «рефакторинг» звучит громче слова «деньги».
Вторая попытка была уже другой. Мы поставили перед старым монолитом тонкий фасад-прокси, который умел маршрутизировать трафик между старым и новым кодом. Дальше мы вырезали систему по кускам, как принято говорить — по bounded context: сначала уведомления, потом расчёт стоимости услуг, потом касса и платежи. Каждую неделю в продакшене появлялось маленькое, но живое изменение. Бизнес не заметил старта модернизации, потому что для него вообще ничего не изменилось — и это было лучшим показателем качества нашей работы.
Технически нас спасли несколько скучных вещей. Во-первых, характеризующие тесты: мы просто зафиксировали текущее поведение старого кода, включая все странности, и получили страховку от неожиданностей. Во-вторых, теневой трафик и сравнение ответов: новый обработчик получал те же запросы, а расхождения мы разбирали руками. В-третьих, двойная запись с ежедневной сверкой балансов и отдельной панелью для расхождений. И, конечно, фича-флаги с постепенным включением на один, десять, пятьдесят процентов и рубильник, который возвращал всё назад за минуту. Без рубильника мы бы никогда не решились выпускать изменения в пятницу вечером.
Отдельная история — разговор с бизнесом. Мы перестали просить большой бюджет на «модернизацию ради модернизации» и начали говорить на языке стоимости владения. Сколько часов в месяц команда тратит на ручные правки. Сколько стоит одна ошибка в кассе. Сколько времени проходит от идеи фичи до её появления у клиента. Когда мы показали, что срок выпуска упал с трёх недель до двух дней, а количество инцидентов за квартал сократилось вдвое, разговоры про «зачем вообще что-то трогать» закончились сами собой. Деньги — лучший аргумент в споре о легаси.
Теперь про грабли, на которые я наступал лично. Мы сильно недооценили миграцию данных и потратили на неё больше времени, чем на весь новый код. Одна команда, которая одновременно поддерживает старое и строит новое, быстро выгорает, если не ограничивать поток доработок в старый монолит. Мы забыли про аналитиков и внешние отчёты, которые читали базу напрямую, — пришлось срочно делать совместимые представления. И главное: не стоит гасить старую систему раньше, чем она отработает в параллельном режиме хотя бы полный отчётный квартал, включая закрытие периода.
Если сжимать мой опыт в короткие рекомендации, получится примерно так. Разбивайте путь на маленькие шаги, каждый из которых самостоятельно приносит пользу. Обязательно имейте план отката и рубильник, который не требует ночного дежурства всей команды. Измеряйте не строки кода, а деньги, время до релиза и количество инцидентов. И уважайте legacy: он выжил там, где многие красивые архитектуры уже умерли, значит, в нём есть скрытая логика, которую стоит сначала понять, а потом менять. А у вас был проект, где старое удалось аккуратно расплести, а не сломать? Что помогло больше — тесты, фича-флаги, теневой трафик или просто терпение бизнеса? Поделитесь историей, очень интересно сравнить опыт.
Расскажу про свой самый показательный проект. Онлайн-запись и приём платежей для сети клиник: монолит на старом PHP, jQuery, MySQL без единого внешнего ключа, миграции руками, а деплой через FTP по пятницам. Писал всё это один человек, который уволился четыре года назад и оставил после себя документацию в виде трёх сообщений в корпоративном чате. При этом система стабильно обслуживала десятки тысяч записей в месяц, и никто в бизнесе не хотел слышать слово «остановка», даже на техническое окно в одну ночь.
Первая наша попытка была классической ошибкой. Мы выбили бюджет, собрали команду из шести человек и год с лишним писали «правильную» систему на современном стеке. Бизнес за это время пять раз поменял требования, мы отставали от графика, а на демо получали вежливое «а где привычные отчёты и интеграция с лабораторией». В итоге вместо запуска мы получили выгоревшую команду и сильно подорванное доверие заказчика. С тех пор я настороженно отношусь к проектам, где слово «рефакторинг» звучит громче слова «деньги».
Вторая попытка была уже другой. Мы поставили перед старым монолитом тонкий фасад-прокси, который умел маршрутизировать трафик между старым и новым кодом. Дальше мы вырезали систему по кускам, как принято говорить — по bounded context: сначала уведомления, потом расчёт стоимости услуг, потом касса и платежи. Каждую неделю в продакшене появлялось маленькое, но живое изменение. Бизнес не заметил старта модернизации, потому что для него вообще ничего не изменилось — и это было лучшим показателем качества нашей работы.
Технически нас спасли несколько скучных вещей. Во-первых, характеризующие тесты: мы просто зафиксировали текущее поведение старого кода, включая все странности, и получили страховку от неожиданностей. Во-вторых, теневой трафик и сравнение ответов: новый обработчик получал те же запросы, а расхождения мы разбирали руками. В-третьих, двойная запись с ежедневной сверкой балансов и отдельной панелью для расхождений. И, конечно, фича-флаги с постепенным включением на один, десять, пятьдесят процентов и рубильник, который возвращал всё назад за минуту. Без рубильника мы бы никогда не решились выпускать изменения в пятницу вечером.
Отдельная история — разговор с бизнесом. Мы перестали просить большой бюджет на «модернизацию ради модернизации» и начали говорить на языке стоимости владения. Сколько часов в месяц команда тратит на ручные правки. Сколько стоит одна ошибка в кассе. Сколько времени проходит от идеи фичи до её появления у клиента. Когда мы показали, что срок выпуска упал с трёх недель до двух дней, а количество инцидентов за квартал сократилось вдвое, разговоры про «зачем вообще что-то трогать» закончились сами собой. Деньги — лучший аргумент в споре о легаси.
Теперь про грабли, на которые я наступал лично. Мы сильно недооценили миграцию данных и потратили на неё больше времени, чем на весь новый код. Одна команда, которая одновременно поддерживает старое и строит новое, быстро выгорает, если не ограничивать поток доработок в старый монолит. Мы забыли про аналитиков и внешние отчёты, которые читали базу напрямую, — пришлось срочно делать совместимые представления. И главное: не стоит гасить старую систему раньше, чем она отработает в параллельном режиме хотя бы полный отчётный квартал, включая закрытие периода.
Если сжимать мой опыт в короткие рекомендации, получится примерно так. Разбивайте путь на маленькие шаги, каждый из которых самостоятельно приносит пользу. Обязательно имейте план отката и рубильник, который не требует ночного дежурства всей команды. Измеряйте не строки кода, а деньги, время до релиза и количество инцидентов. И уважайте legacy: он выжил там, где многие красивые архитектуры уже умерли, значит, в нём есть скрытая логика, которую стоит сначала понять, а потом менять. А у вас был проект, где старое удалось аккуратно расплести, а не сломать? Что помогло больше — тесты, фича-флаги, теневой трафик или просто терпение бизнеса? Поделитесь историей, очень интересно сравнить опыт.