Compacting conversation...

Forwarded from do...while...ai (Gregory is typing...)

Рефакторинг вайбкодинга

Все последние проекты, которые я разрабатывал (процентов на 80 вайбкодил), всегда проходят через две фазы: разработки и рефакторинга, и циклически повторяют их.

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

Почему не делать это сразу в момент ревью результатов? Это замедляет реализацию бизнес-функций. Но откровенный булщит, конечно, исправляю сразу.

Как человек ленивый, первое, что я попробовал — это делать автоматический рефакторинг. Написал огромную инструкцию о том, как делать рефакторинг поэтапно (для python backend, деплоя, фронта на reactjs, ..), как запускать тулзы типа vulture, flake8, ESlint, Skylos, и т.п. для диагностики и валидации результатов, задал пороговые значения и параметры рефакторинга, позапускал с разными агентами (я попеременно использую Cursor, Claude Code и Codex). И то, что получалось в итоге — было фиаско.

Увы, пока ни агенты, ни модели, не работают на должном уровне, чтобы автономно по инструкциям сделать грамотный и эффективный рефакторинг. Поэтому данный этап я всё ещё делаю ручками. Открываю файлы, которые недавно менялись, начинаю ревьюить, замечать какие-то кривости реализации (например, сегодня у меня в трех местах в ansible playbook'ах была однотипная проверка на ОС на целевом хосте). Как только обнаруживаются проблемы реализации — я даю команду курсору или Codex исправить её: описываю, что и где я нашёл, почему я считаю это неэффективным, как я предлагаю реализовать, настаиваю на том, чтобы не было breaking changes и сохранилась вся текущая функциональности, и прошу также прошерстить остальной код на предмет аналогичных проблем. Если просить модель саму решить, как лучше отрефакторить, часто получается не лучше, чем было. Поэтому здесь нужно это брать в свои руки.

Я выработал свой критерий успешности рефакторинга: размер кода должен уменьшиться при сохранении функциональности и 100% pass rate для тестов.
Если я вижу, что переделка кода удалила 400 строк и добавила 390 — это какая-то фигня. Отменяю и делаю новую итерацию.

Типичные проблемы, которые я замечаю при вайб-кодинге, и для чего я делаю принудительный рефакторинг:
- дубли кода (иногда явно задублированный код в разных файлах)
- "мёртвый" код (модель переписывает что-то, забывая удалить старый, и оно там остаётся на века, засоряя проект)
- ненужный избыточный код, сохранённый для обратной совместимости (которая не нужна). Это прямо бич всех агентов: они стараются быть аккуратными и лишний раз реализуют избыточный код для сохранения обратной совместимости, которая не нужна.
- избыточные комментарии и код для дебага (когда агент что-то дебажит, он добавляет кучу ненужного для прода кода, и потом его не удаляет)
- .md файлы с документированием изменений (удаляю их сразу после завершения сессии). Пробовал делать рулзы не создавать эти .md, если я явно не прошу, но Cursor забивает на часть моих рулзов.
- лоскутное одеяло из стилей кодирования (где-то файлы читаются через file read(), где-то через pathlib read_text())
- константы и импорты объявляются локально внутри try / catch блоков или функций.

Важное наблюдение: поскольку природа LLM — completion inference, модель учитывает и "продолжает" стиль существующего кода. Если сделать заготовку проекта, написанную "с нуля" хорошо и аккуратно, есть шанс, что модель продолжит дальше вайбкодить также хорошо, как по трафарету (до определенного момента, конечно). Поэтому аккуратность кода нужно поддерживать регулярно, и, увы, вручную. Именно это я и пытаюсь делать регулярными рефакторингами проектов.

566 views11:15