Рефакторинг или переписать заново — и почему агент всегда советует второе

Показываешь агенту запутанный файл и спрашиваешь, что с ним делать. Ответ почти наверняка будет: «давай перепишу с нуля, так будет чище».

Звучит разумно. И вот что стоит знать перед тем, как согласиться: модель предлагает это не потому, что так лучше. А потому, что переписать ей дешевле, чем понять.

Написать двести новых строк для неё — прямая задача. Удержать в голове, почему твои двести старых написаны именно так, с тремя костылями и странным условием посередине, — гораздо сложнее. Переписывание — путь наименьшего сопротивления, и он выглядит как совет.

Разберёмся, когда он действительно совет.

Чем рефакторинг отличается от переписывания

Разница одна, но она определяет всё остальное.

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

Переписывание — выбрасываешь код и делаешь заново. Сохраняется только намерение: «эта штука должна показывать список задач». Как именно — заново решаешь ты.

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

Пять критериев

Вот оси, на которых решение реально принимается — а не «что красивее».

1. Что сохраняется

• Рефакторинг: поведение целиком, включая неочевидное. Все мелкие «а вот тут оно ещё и вот так умеет» переживают правку.
• Переписывание: только то, что ты помнишь и записал. Всё остальное теряется молча.

2. Риск

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

3. Чем проверяешь

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

4. Когда виден результат

• Рефакторинг: сразу. Каждый шаг — законченный, проект всё время рабочий.
• Переписывание: в конце. Посередине у тебя две недостроенные версии и ничего работающего.

5. Что делать с известным багом

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

Сведём к одной строке: рефакторинг меняет форму при известном содержании, переписывание меняет и то и другое одновременно. Поэтому второе почти всегда дороже, чем кажется на старте.

Почему модели голосуют за «переписать»

Три причины, и ни одна из них не про качество твоего кода.

Во-первых, контекст. Агент видит файл, но не видит историю: кто, когда и от какой боли добавил это условие. Для него странная строчка — просто странная строчка.

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

В-третьих, уверенность не равна знанию. Модель одинаково уверенно пишет и то, что проверено, и то, что придумано. Про это стоит помнить всегда — в том числе когда она объясняет, почему старый код плох.

История, кстати, старше нейросетей. Классический разбор Джоэла Спольски 2000 года о том, как Netscape решил переписать браузер с нуля, разошёлся именно из-за вывода: переписывание съело годы, а конкуренты за это время просто чинили своё по кусочкам. Соблазн «начать с чистого листа» — древний и очень человеческий.

Кому что подойдёт

Без виляния.

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

Переписывай, если совпали оба условия сразу:

1. Ты не можешь объяснить, что код делает, даже после того как попросил модель разобрать его построчно.
2. У тебя есть чем проверить новую версию — тесты или хотя бы честный письменный список сценариев, которые обязаны работать.

Одного условия мало. Не понимаешь код и проверить нечем — не переписывай, сначала сделай второе. Написать список из пятнадцати сценариев — это час. Восстанавливать потерянное поведение по жалобам пользователей — это месяц.

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

Если всё-таки переписываешь — три правила

1. Сначала зафиксируй поведение, потом трогай код. Список сценариев или тесты — до, не после. Иначе эталон останется только в голове.
2. Не удаляй старое. Пусть лежит рядом, пока новое не проживёт неделю в бою. Коммит с рабочей версией — твоя единственная кнопка «назад».
3. Переписывай кусками, которые можно выпустить. Один экран, один модуль. Переписывание, которое нельзя выкатить частями, имеет привычку не заканчиваться никогда.

И маленький приём на каждый день. Прежде чем соглашаться на «перепишу», задай агенту другой вопрос: «объясни построчно, что делает этот код и зачем здесь каждое условие». Иногда выясняется, что код нормальный, а непонятным был из-за двух плохих имён переменных. Тогда вся работа — переименовать. Это и есть рефакторинг в чистом виде — и разбираться в незнакомом коде модели умеют куда лучше, чем угадывать, что в нём было важно.

Рефакторинг должен менять поведение?

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

Можно ли попросить ИИ отрефакторить, а не переписать?

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

Сколько кода стоит переписывать за раз?

Столько, сколько ты готов проверить за один присест. Практический ориентир — один экран или один модуль. Если объём такой, что проверить можно только «потом как-нибудь», кусок слишком большой.