Проблема «тихого провала» при рефакторинге
Ключевая проблема автоматизированного рефакторинга — ложное чувство безопасности. Новый код может проходить тесты, написанные для старого, но вести себя иначе на неочевидных входных данных. Anthropic решает это через плагин code-modernization, который внедряет процесс proof-of-behavior (доказательство поведения). Плагин не доверяет мнению модели, а использует скриптовую проверку, сравнивая байты выходных данных старой и новой систем.
Три стратегии модернизации
Плагин поддерживает три сценария работы с кодовой базой, от простого обновления зависимостей до полной перестройки архитектуры. Выбор стратегии зависит от объема изменений, необходимых для совместимости:
| Команда | Сценарий | Что происходит |
|---|---|---|
uplift |
Обновление версии (например, .NET Framework → .NET 8) | Код сохраняется, исправляются только ломающие изменения. Использует каталог брейкинг-чейнджей. |
transform |
Перенос модуля на новую технологию | Идиоматический перепис модуля при сохранении работающей старой системы. Требует пошагового утверждения плана. |
reimagine |
Реконструкция на новой архитектуре | Генерация спецификации из кода, создание микросервисов с исполняемыми acceptance-тестами. |
Механика верификации: как работает «Proof»
После сборки нового кода запускается команда modernize-verify. Она не просто запускает тесты, а проводит стресс-тестирование на основе эвристик:
- Сравнение на одних и тех же данных: Старая и новая версии запускаются на одних и тех же входных данных. Скрипт сравнивает вывод посимвольно, маскируя только неизменяемые поля (таймстампы, ID).
- Генерация «враждебных» входных данных: Система генерирует минимум 10 новых тестовых случаев (границы, пустые значения, некорректные форматы), которые модель могла упустить. Если новый код проходит только на «любимых» данных, он помечается как непроверенный.
- Canary-тесты: В код намеренно вносится однострочная ошибка, чтобы убедиться, что система тестирования способна отловить регрессию.
Результаты и статусы
Каждый модуль получает один из трех вердиктов, вычисляемых на основе текущих доказательств:
- PROVEN: Все критические бизнес-правила (P0) подтверждены прошедшими тестами.
- PARTLY PROVEN: Частичное совпадение (например, если старая система недоступна для запуска, верификация идет по записанным логам).
- NOT PROVEN: Тесты не запускались, есть расхождения или сбой.
Безопасность и контроль
Плагин не редактирует исходный код легаси. Все изменения пишутся в папки analysis/ и modernized/. Процесс требует участия человека в 6 ключевых точках: подтверждение готовности окружения, исправление неверных бизнес-правил, утверждение плана модернизации, принятие расхождений в тестах, подпись акта верификации и применение патчей безопасности. Это делает инструмент пригодным для enterprise-сред, где автоматизация не заменяет ответственность архитектора.
Источник: Github ↗