Что такое рефакторинг — зачем менять код, который работает

Есть странная работа: час правишь код — а к концу приложение делает ровно то же, что и утром. Ни одной новой кнопки. И это считается хорошо потраченным часом.

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

Что такое рефакторинг

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

Аналогия — навести порядок на кухне. Ты не готовишь новых блюд: раскладываешь ножи по местам, выбрасываешь три одинаковые открывашки, подписываешь банки. Ужин сегодня тот же. Но готовить завтра — быстрее и приятнее.

Термин закрепил Мартин Фаулер — его книга «Refactoring» вышла ещё в 1999-м. Проблема старше ИИ: код пишут один раз, а читают десятки.

Зачем трогать то, что работает

«Работает — не трогай» звучит мудро, но у этого правила есть срок годности.

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

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

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

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

Три типовых примера — заметь, ни один не меняет поведения:

• Переименовать. Была переменная data, стала userList. Код делает то же, но следующий читатель (ты через месяц) не гадает, что внутри.
• Вытащить повторы. Один и тот же кусок в трёх местах — превращается в одну функцию, которую зовут трижды. Чинить теперь нужно в одном месте.
• Разрезать простыню. Файл на восемьсот строк — на три файла по смыслу: логика, интерфейс, работа с данными.

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

Кстати, у сигналов «пора прибраться» есть своё имя — «запахи кода» (code smells). Дублирование, функция на двести строк, имя data2 — это они. Встретишь термин в ответе ИИ — знай: он про поводы для рефакторинга, а не про реальные поломки.

Как рефакторить с ИИ

Тут четыре правила, и они дешёвые.

1. Не смешивай. «Добавь фичу и заодно почисти код» — худший промпт: если что-то сломается, не поймёшь, какая из двух правок виновата. Один заход — одна цель.
2. Сначала коммит. Перед уборкой сохрани рабочее состояние — коммит даст точку, куда всегда можно откатиться.
3. Проси явно. Формула: «Отрефакторь этот файл. Поведение не меняй. Объясни каждое изменение». Последняя часть — твой контроль: непонятное объяснение — повод спросить, а не принять.
4. Проверь сам. После рефакторинга прогони приложение по основным сценариям. Обещание «поведение не изменилось» проверяется глазами, а не на слово — это часть навыка читать код от ИИ.

Бонус: ИИ сам иногда предлагает «давай отрефакторим». Теперь ты знаешь, что он имеет в виду — и можешь согласиться осознанно, отдельным заходом.

Рефакторинг — это то же, что оптимизация?

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

Как часто нужно рефакторить?

Понемногу и постоянно, а не «большой уборкой раз в год». Хорошее правило бойскаута: оставь код чуть чище, чем нашёл. Заметил непонятное имя, пока делал фичу, — переименуй следующим заходом.