Технический долг в вайбкод-приложении: увидеть, оценить, выплатить

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

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

У обычного проекта долг растёт от спешки: срезали угол, обещали вернуться. У вайбкод-проекта — от того, что каждый промпт решал задачу с нуля.

• Один и тот же код в пяти местах. Валидация формы, расчёт цены, проверка тарифа скопированы в каждый компонент, где понадобились, и уже немного разные.
• Несколько способов на всё. Данные загружаются тремя разными библиотеками, состояние живёт и в контексте, и в сторе, и в адресной строке — смотря какой промпт это писал.
• Мёртвый код. Брошенные варианты экранов, неиспользуемые функции, компоненты PricingOld и PricingNew2.
• Нет границ. Компоненты интерфейса ходят в базу напрямую, бизнес-правила живут в обработчиках кнопок, типы на границе с API — any.

Где искать

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

История изменений показывает, какие файлы правятся чаще всего:

git log --since="6 months ago" --format= --name-only \
  | sort | uniq -c | sort -rn | head -20

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

Дальше — спроси команду. Где оценки задач всегда оказываются заниженными? Какие места все обходят? Что приходится объяснять каждому новому человеку? Ответы обычно совпадают с тем, что показал git.

Как оценить

Каждой позиции долга нужны две оценки: сколько стоит её исправить и сколько она стоит, пока не исправлена. Вторая важнее, и её чаще забывают.

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

Заведи простой реестр: что, где, чем мешает, сколько стоит исправить. Не больше двадцати позиций — длинный список никто не читает.

Как выплачивать, не останавливая работу

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

• Гаси долг там, где работаешь. Задача касается расчёта цены — значит, в её рамках расчёт сводится в одно место. Долг гасится рядом с функциями, а не вместо них.
• Постоянная доля. Договорись, что заметная часть каждого цикла — скажем, пятая — уходит на позиции из реестра. Не «если останется время», а заранее.
• Сначала то, что мешает чаще. Сортируй реестр не по уродству, а по тому, как часто позиция встаёт на пути.
• Удаляй. Мёртвый код — самый дешёвый долг: его не надо переписывать, его надо убрать. Начни с этого, результат видно в тот же день.
• Закрепляй. Сведя логику в одно место, добавь тест и правило линтера, чтобы следующий промпт не размножил её снова.

Как понять, что становится лучше

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

SUBXCAT помогает составить такой реестр для проекта, собранного с ассистентом, и выплачивать его параллельно с разработкой.