Переход на современный фреймворк: Rewrite или Refactor?

Зачем вообще мигрировать?

Вы когда-нибудь слышали от заказчика: «Приложение работает — зачем его трогать?» Это логичный вопрос, особенно если продукт приносит деньги и не ломается. Но правда в том, что откладывание миграции только увеличивает технический долг и угрожает безопасности. В этой статье я поделюсь опытом переезда с устаревших стеков (Angular 7, Backbone) на современные фреймворки, и вы узнаете, как выбрать между полным переписыванием и инкрементальным рефакторингом.

Почему миграция — это вопрос выживания продукта

Когда библиотека устаревает и перестаёт получать патчи безопасности, ваше приложение становится уязвимым. Ни один продакт-оунер не скажет: «Давайте пожертвуем безопасностью ради фич». Кроме того, современные инструменты сборки (Vite, Webpack 5) дают огромный прирост производительности. А скорость загрузки напрямую влияет на пользовательский опыт и конверсию. Главное правило: чем дольше вы откладываете миграцию, тем она дороже и сложнее.

Два пути: Rewrite (Big Bang) vs Refactor (Strangler Pattern)

Все стратегии миграции сводятся к двум подходам:

• Rewrite (Big Bang) — полное переписывание или прямое обновление фреймворка до последней версии.
• Refactor (Strangler Pattern) — поэтапная замена частей приложения, пока работает старый функционал.

Какой выбрать? Всё зависит от контекста. Если приложение небольшое, команда опытная, а документация в порядке — Big Bang может быть быстрее и дешевле. Если же проект огромен, фичи нужно поставлять непрерывно, а в команде много джунов — Strangler Pattern ваш спаситель.

Сравнение подходов

• Размер приложения: Rewrite — малый/средний; Refactor — большой.
• Разработка фич: Rewrite — можно остановить; Refactor — должна продолжаться.
• Документация: Rewrite — хорошая; Refactor — плохая.
• Опыт команды: Rewrite — высокий; Refactor — смешанный.
• Толерантность к риску: Rewrite — выше; Refactor — ниже.
• Время до первых результатов: Rewrite — короткое; Refactor — долгое.
• Сложность во время миграции: Rewrite — ниже; Refactor — выше.
• Риск бесконечной миграции: Rewrite — низкий; Refactor — высокий.

Реальный пример: Big Bang с Angular 7 на современный Angular

Представьте: приложение на Angular 7, которое годами не обновляли, потому что оно было в режиме поддержки. Затем стейкхолдеры решили расширить функционал. Мы убедили их обновиться до последней версии Angular — в первую очередь из-за безопасности.

Четыре разработчика справились за четыре месяца. Но было тяжелее, чем ожидалось. Главная проблема — не сам фреймворк, а экосистема. Например, библиотека компонентов между версиями 12 и 13 ввела критические изменения в синтаксисе. Некоторые сторонние библиотеки оказались заброшены — если пакет не обновлялся годами и не компилируется на Node 18, это бомба замедленного действия.

# Пример: проверка устаревших зависимостей
import pkg_resources

installed = [d for d in pkg_resources.working_set]
old_packages = [p for p in installed if p.key in ['deprecated-lib']]
if old_packages:
    print(f'Найдены устаревшие: {old_packages}')
else:
    print('Всё чисто')

Итог: время сборки сократилось, размер бандла уменьшился, новый UI понравился даже скептикам. QA-команда, которая сначала нас ненавидела, признала: регулярные обновления лучше, чем раз в семь лет.

Реальный пример: Strangler Pattern с Backbone на Vue

Стартап, старое приложение на Backbone. Однажды продажи продали фичу, которой ещё не существовало, и дали три месяца на реализацию. Строить новую фичу на Backbone? Нет уж.

Мы создали новое приложение на Vue рядом со старым. Поставили reverse proxy, который направлял запросы в зависимости от роута. Сначала перенесли экран логина как proof of concept, затем новую фичу. В течение года мы мигрировали экран за экраном. Backbone исчез полностью, клиенты ничего не заметили.

# Пример конфигурации nginx для Strangler Pattern
server {
    listen 80;
    server_name example.com;

    location /new-feature {
        proxy_pass http://vue-app:3000;
    }
    location / {
        proxy_pass http://backbone-app:8080;
    }
}

Но есть и минусы: процесс занял целый год, и была опасность «бесконечной миграции», когда фичи постоянно отвлекают от рефакторинга. Кроме того, разработчики не любят трогать legacy-код, но это неизбежно.

Практический вывод: что делать прямо сейчас

Проанализируйте своё приложение по таблице выше. Если проект маленький и команда готова — выбирайте Big Bang. Если нет — начинайте Strangler Pattern с одного маршрута. И помните: откладывание миграции только усугубляет проблему. Начните с аудита зависимостей и выберите первую цель для рефакторинга уже сегодня.