Когда использовать
Когда код работает, но «страшный» — длинные функции, дубли, нечитаемо, и надо причесать, ничего не сломав. Роль — аккуратный инженер. Результат: чистый код + журнал «было → стало → зачем» + что проверить тестами.
Промт (бери и вставляй)
Ты — инженер, который рефакторит аккуратно. Перепиши код ниже чище, НЕ меняя его внешнее поведение.
КОД: «<ВСТАВЬ>». ЯЗЫК/СТИЛЬ: <напр. TS, без any; PEP8>.
Жёсткие правила:
- Поведение и публичный интерфейс не меняем. Имена в API не ломаем.
- Никаких новых зависимостей без явного обоснования.
- Маленькие безопасные шаги, а не переписывание с нуля.
Выдай: 1) переписанный код; 2) список изменений «было → стало → зачем»; 3) что проверить тестами, чтобы убедиться, что поведение не поехало.
Пример заполнения
В <ВСТАВЬ> — функция на 80 строк с тремя вложенными if и копипастой валидации. Язык: TS, без any.
Ожидаемый ответ ИИ: (1) функция разбита на 3 маленькие (validateInput, computeTotal, format), ранние return вместо вложенности, типы вместо any; (2) журнал — «вложенные if → guard-clauses, зачем: читаемость», «дубль валидации → общая функция»; (3) проверить тестами те же входы/выходы, что и раньше, особенно края, где менялась логика ветвлений.
Вариации
- Точечно. «Только убери дублирование» или «только разнеси на функции» — минимальный диф.
- Под паттерн. «Перепиши под dependency injection / на чистые функции».
- Сначала тесты. Связка: сперва промт «Написать тесты», потом рефакторинг под защитой характеризующих тестов.
Про-советы
- Золотое правило: рефакторинг под зелёными тестами. Нет тестов? Сначала напишите характеризующие — иначе «ничего не сломал» нечем подтвердить.
- «Маленькие шаги» в промте не зря: на просьбу «перепиши красиво» модель любит переписать с нуля и тихо поменять поведение.
- Журнал «было → стало → зачем» — для ревью диффа: читайте его, а не только новый код, чтобы поймать скрытые изменения смысла.