Рефакторинг legacy-кода с помощью AI: где помогает, а где мешает

Унаследованный код — это код, который работает, но никто точно не знает почему. Именно на таком материале ожидания от AI расходятся с реальностью сильнее всего: модель прекрасно справляется с одной половиной задачи и системно проваливает другую.

Главная ценность — объяснение, а не переписывание

Самый заметный выигрыш возникает там, где нужно понять чужой код. Функция на четыреста строк без комментариев, с переменными $tmp2 и вложенностью в шесть уровней разбирается за минуты вместо часов.

Особенно полезны конкретные вопросы, а не просьба «объясни»:

• Какие входные данные приводят к тому, что выполнение доходит до этой ветки?
• Что здесь меняется в базе, а что только в памяти?
• Где эта функция вызывается и что ожидается от её результата?
• Какие побочные эффекты произойдут, если убрать этот блок?

Ответы всё равно нужно проверять, но они дают карту местности — а на легаси именно её отсутствие съедает больше всего времени.

Тесты до рефакторинга, а не после

Рефакторинг без тестов на легаси — это не рефакторинг, а переписывание с надеждой. И вот здесь AI даёт второй крупный выигрыш: писать характеризующие тесты скучно, а модель делает это быстро.

Смысл характеризующего теста не в том, чтобы зафиксировать правильное поведение, а в том, чтобы зафиксировать текущее — включая странности. Если функция при пустом массиве возвращает строку вместо числа, это идёт в тест как есть. Возможно, на эту особенность где-то опираются.

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

Где AI ошибается на легаси

Ошибки здесь не случайные, а системные, и знать их полезно заранее:

• Принимает баг за баг. Модель видит странность и «исправляет» её. А эта странность — компенсация другой ошибки, на которую опирается бухгалтерия уже пять лет.
• Не видит неявных связей. Глобальные переменные, обработчики событий, триггеры в базе, крон-скрипты — всё, что не лежит в показанном файле, для модели не существует.
• Уверенно предполагает. Отсутствие информации о вызывающем коде не мешает выдать однозначный вывод о его поведении.
• Улучшает слишком много сразу. Попросили вынести функцию — получили заодно переименованные переменные, изменённые проверки и новый стиль обработки ошибок. Такой диff невозможно ревьюить.
• Теряет специфику платформы. На Bitrix и Drupal модель охотно предлагает «правильный» код, игнорируя штатное API и соглашения платформы.

Порядок работы, который себя оправдал

1. Зафиксировать границы. Что именно меняем и что точно не трогаем. Без этого правки расползаются.
2. Разобраться в логике. С помощью модели, но с проверкой ключевых утверждений по коду.
3. Закрыть участок тестами. Характеризующими, на текущее поведение.
4. Менять мелкими шагами. Один осмысленный шаг — один прогон тестов — один коммит.
5. Читать диффы целиком. Не «выглядит разумно», а построчно. Именно здесь ловится большинство привнесённых ошибок.
6. Отдельно проверять безопасность. Экранирование, проверки прав, параметризация запросов — то, что модель может незаметно потерять при переписывании.

Что не стоит поручать

Есть участки, где скорость не является достоинством:

• Код, где неверный результат приводит к финансовым последствиям, — расчёты цен, скидок, налогов, взаиморасчётов.
• Логика прав доступа: модель охотно упрощает условия и незаметно расширяет доступ.
• Миграции данных, у которых нет обратного пути.
• Места, где вы сами не понимаете требований. Ускорить непонимание — не то, что нужно.

Как понять, что подход работает

Хороший признак — рефакторинг перестал быть страшным. Изменения выходят небольшими порциями, тесты растут вместе с кодом, а объяснение «почему так» появляется в комментариях и коммитах, а не остаётся в голове одного человека.

Плохой признак — обратный: диффы на тысячу строк, тесты добавлены после, а вопрос «почему модель это изменила» остаётся без ответа. В такой конфигурации AI не ускоряет работу, а переносит её на этап отладки в проде.