Когда использовать
Есть легаси (старый фреймворк, мёртвая версия языка, монолит-комок), и нужно его обновить или перенести, не уронив прод и не переписывая всё разом «с чистого листа». В отличие от обычного рефакторинга (улучшить код, не меняя поведения), здесь задача крупнее: сменить технологию/версию пошагово и безопасно. Роль ИИ — инженер по миграциям. Результат: план инкрементального переноса с откатом на каждом шаге.
Промт (бери и вставляй)
Ты — инженер по миграциям легаси. Составь план безопасного переноса. Сначала оценка, потом шаги.
ЧТО МИГРИРУЕМ: «<ВСТАВЬ: с чего на что — фреймворк/версия/архитектура>»
КОД/КОНТЕКСТ: <вставь ключевые файлы или опиши систему, объём, нагрузку, есть ли тесты>
ОГРАНИЧЕНИЯ: <нельзя простой / окно даунтайма X / команда Y>
Выдай:
1. Оценка «как есть»: главные риски легаси, связки, что хрупкое, есть ли страховочная сетка из тестов.
2. Стратегия: разом или инкрементально (strangler-fig — новое рядом, старое гасим по кускам). Обоснуй выбор.
3. Пошаговый план: каждый шаг — МАЛЕНЬКИЙ, самостоятельно деплоится, после него система рабочая. Без «большого взрыва».
4. Для каждого шага: что меняем, как проверяем, как откатываемся, если сломалось.
5. Безопасная сетка: какие тесты/характеристики зафиксировать ДО миграции, чтобы ловить регрессии.
6. Порядок по приоритету: что переносим первым (риск × ценность), что можно оставить напоследок.
Перед необратимыми шагами (схема БД, удаление старого) — явно укажи бэкап/ветку/флаг. Допущения помечай [допущение].
Приём: strangler-fig (новое строим вокруг старого и гасим легаси по кускам) + «каждый шаг деплоится и откатывается» убирают главный риск миграций — «переписали всё, и ничего не работает».
Пример заполнения
Мигрируем: с AngularJS (1.x) на React, монолитный фронт. Контекст: ~40 экранов, тестов почти нет, прод живой. Ограничение: нельзя длинный даунтайн.
Ожидаемый ответ ИИ: оценка — нет тестов = главный риск, начни с e2e на критичные флоу; стратегия — strangler-fig, React-острова внутри Angular через обёртку, миграция по экрану; план — сначала зафиксировать e2e на «оплату» и «логин», затем переносить экраны от простого к сложному, каждый за свой деплой с фиче-флагом; откат — флаг возвращает старый экран; необратимое (выпил Angular-бутстрапа) — в самом конце, отдельной веткой после переноса всех экранов.
Вариации
- Версия языка/рантайма. «Python 2 → 3» или «Node 14 → LTS»: упор на несовместимости, поэтапную сборку и совместимый слой.
- БД-миграция. «Перенос схемы без даунтайма»: expand–contract (добавить новое → дублировать запись → переключить чтение → удалить старое).
- Авто-помощь. «Какие шаги можно отдать codemod/агенту-кодеру, а какие требуют ручного решения» — что автоматизируется.
Про-советы
- Первый шаг любой миграции — НЕ трогать легаси, а накрыть его тестами. Без страховочной сетки вы не узнаете, что сломали.
- Гоните «каждый шаг деплоится сам». План, где «всё включается в конце», — это переписывание под видом миграции, самый частый провал.
- Перед необратимым (схема БД, выпил старого кода) требуйте явный бэкап/ветку/флаг — миграции ломают данные тише и дороже, чем фичи.