Программирование с ИИ
ENRU
3.6

Шаблон — рефакторинг

меняем форму, не трогая поведение

Что это

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

Отсюда главная сложность запроса: надо явно сказать, что поведение менять нельзя. Иначе ИИ воспримет задачу как «сделай лучше» и заодно поправит логику — а это уже не рефакторинг, и проверять придётся всё.

Как выглядит в коде

Шаблон

Запрос
Что не так: <почему код требует переделки>
Что сделать: <какое изменение формы>
Поведение не меняем: <что должно работать ровно как раньше>
Как проверю: <чем убедимся, что не сломали>

Плохо

Не так
Отрефактори handlers/weather.py, сделай покрасивее

«Покрасивее» — приглашение переписать файл с нуля. Получишь другую архитектуру, другие имена, попутно исправленные (или сломанные) граничные случаи и дифф, который невозможно прочитать.

Хорошо

Лучше
Что не так: функция cmd_weather на 80 строк, в ней смешаны
запрос к API, разбор ответа и формирование текста.

Что сделать: разбей на три функции — fetch, parse, format.
cmd_weather оставь точкой входа, она только вызывает их по очереди.

Поведение не меняем: тексты ответов пользователю, формат логов
и обработка ошибок остаются ровно такими же, до символа.

Как проверю: прогоню те же три команды, что и раньше, и сравню
ответы бота дословно.

Как сказать ИИ

Фраза, без которой не стоит начинать

Поведение не меняем.

Её надо писать прямо, даже если кажется, что это и так понятно из слова «рефакторинг». Для ИИ это слово размыто: в обучающих данных им называют и переименование переменной, и переписывание модуля с нуля.

Рефакторинг и фича — разные заходы

Соблазн велик: раз уж лезем в этот файл, давай заодно добавим кеш. Так делать не надо — и вот почему. Если после правки что-то сломается, ты не будешь знать, сломал это рефакторинг или новая фича. Разделённые, они диагностируются мгновенно; смешанные — часами.

Запрос
Сначала только разбей на функции, без изменений поведения.
Кеш добавим следующим шагом, отдельно.

Чем проверять

Лучше всего — тестами: прогнал до, прогнал после, результат совпал. Если тестов нет, годится и ручная проверка, но её надо описать заранее, иначе после правки окажется, что сравнивать не с чем.

Приём, который стоит минуты: до рефакторинга сохрани вывод программы на нескольких входах в файл. После — сравни.

python bot.py --dry-run > before.txt
# ... рефакторинг ...
python bot.py --dry-run > after.txt
diff before.txt after.txt

Пустой diff — рефакторинг прошёл чисто.

На что смотреть

Дифф больше, чем должен быть. Разбиение функции на три — это перемещение строк, а не их переписывание. Если в диффе почти каждая строка изменена, значит, код переписали заново, и поведение почти наверняка поехало.

Изменились тексты. Самое частое непрошеное улучшение: ИИ «причёсывает» сообщения пользователю. Было «Город не найден», стало «К сожалению, указанный город не найден 😔». Мелочь, но это уже изменение поведения.

Появились новые зависимости или абстракции. Базовый класс, фабрика, декоратор — там, где просили просто разбить функцию. Признак того, что ИИ решал свою задачу, а не твою.

Исчезла обработка краёв. Проверка на пустой список, if not data, ранний return — при переписывании такие строки теряются первыми, потому что выглядят необязательными.

Шпаргалка

  • Четыре строки: что не так · что сделать · поведение не меняем · как проверю.

  • «Поведение не меняем» пиши явно, слово «рефакторинг» этого не гарантирует.

  • Рефакторинг и фича — разные заходы и разные коммиты.

  • Сохрани вывод до и после, сравни через diff.

  • Большой дифф при разбиении функции — код переписали, а не переставили.