Что такое "удушающая смоковница" и переписывание с нуля?
Когда вы сталкиваетесь с монолитом, который давно пора модернизировать, перед вами встаёт выбор: разложить его на микросервисы постепенно или переписать всё заново. Первый путь — это шаблон "удушающей смоковницы" (Strangler Fig Pattern), второй — полный рефакторинг с нуля. Оба подхода имеют свои плюсы, минусы и подводные камни. Давайте разберёмся, чем они отличаются и когда стоит использовать каждый.
Шаблон удушающей смоковницы: эволюция, а не революция
Название шаблона отсылает к тропическому дереву, которое обволакивает старое дерево и со временем полностью его заменяет. В программировании это означает постепенное замещение старого кода новым, без остановки системы.
Как это работает на практике:
1. Вы выделяете часть функционала монолита, которую можно вынести.
2. Создаёте микросервис, реализующий эту функциональность.
3. Перенаправляете трафик с монолита на новый сервис через API Gateway или маршрутизатор.
4. Повторяете процесс, пока весь монолит не исчезнет.
Преимущества:
- Минимизация рисков — вы не выбрасываете всё сразу.
- Можно быстро получить обратную связь по каждому шагу.
- Удобно тестировать гипотезы и архитектурные решения.
Подводные камни:
- Интеграция старого и нового кода может быть сложной.
- Технический долг никуда не девается — он просто "живет рядом".
- Требуется хорошее покрытие тестами и мониторинг.
Переписывание с нуля: чистый лист, но с риском
Полный рефакторинг — это когда вы выбрасываете старый код и начинаете с нового проекта. Всё по канонам: новая архитектура, современные фреймворки, чистый домен.
Плюсы:
- Возможность избавиться от архитектурных ошибок прошлого.
- Вы можете использовать новейшие технологии и практики.
- Нет зависимости от старого кода.
Минусы:
- Высокий риск провала. По статистике, до 70% таких переписей оказываются неудачными.
- Долгое время до первого результата.
- Часто недооценивается сложность и объём старой системы.
Нестандартные стратегии: гибриды и нестандартные подходы
Иногда классические шаблоны не подходят или кажутся слишком прямолинейными. Вот несколько альтернативных стратегий, которые можно рассмотреть:
1. "Теневая миграция" (Shadow Migration)
Вы запускаете новый микросервис параллельно с монолитом, но не направляете на него пользовательский трафик. Вместо этого он "слушает" запросы, обрабатывает их и сравнивает результаты с монолитом. Это помогает выявить расхождения и баги до реального запуска.
2. Инверсия зависимости через BFF (Backend For Frontend)
Создайте слой BFF, который будет абстрагировать UI от бизнес-логики. Это позволит вам менять бэкенд без изменения фронтенда. Отлично подходит для постепенной миграции.
3. "Песочница для новых сервисов"
Разрешите новым микросервисам работать только с частью данных или пользователей (например, A/B тестирование). Это снижает риски и ускоряет внедрение.
Когда выбрать удушающую смоковницу, а когда переписывать с нуля?
Вот несколько критериев, которые помогут вам определиться:
- Если у вас есть жёсткие сроки или бизнес не может остановиться — выбирайте шаблон удушающей смоковницы.
- Если система настолько запутана, что разобраться невозможно — возможно, переписывание с нуля будет дешевле.
- Если команда небольшая и не хватает ресурсов на поддержку двух систем одновременно — лучше начать с MVP нового сервиса и развивать его отдельно.
Частые ошибки и как их избежать
- Переоценка своих сил. Не думайте, что переписать систему за 3 месяца — это реально. Заложите в 2-3 раза больше времени.
- Отсутствие автоматических тестов. Без них вы не сможете безопасно переписывать или выносить функционал.
- Работа без мониторинга. Вы должны видеть, как ведёт себя каждый сервис после миграции.
Советы для новичков
- Начинайте с самого стабильного и простого функционала.
- Не бойтесь оставить часть кода в монолите надолго — он не враг, а временное решение.
- Всегда документируйте миграцию: что, зачем и как было сделано.
Вывод
Удушающая смоковница — это стратегия для тех, кто хочет двигаться аккуратно. Переписывание с нуля — путь смелых, но рискованных. А иногда лучше всего работает что-то среднее: гибридная миграция, тестовые окружения, временные адаптеры. Главное — не забывайте, что архитектура — это не цель, а средство. И она должна служить бизнесу, а не наоборот.
