- Технический долг стоит оценивать по тому, сколько сил повторно уходит на изменения, чем грозят сбои и что продукту предстоит дальше.
- Список замечаний анализатора помогает искать проблемы, но сам по себе не определяет очередь исправлений.
- В оценку рефакторинга нужно включать проверку, выпуск и возможность отката: переписанным кодом работа не заканчивается.
- Стабильный участок без существенных рисков и планируемых изменений иногда выгоднее оставить в покое.
- ИИ можно поручить ограниченное исправление с критериями приёмки. За последствия отвечает инженер.
Как оценить технический долг: начните с карточки проблемы
28 октября 2026 года Sonar опубликовала разбор о том, как генерация кода может обгонять способность команды проверять изменения. Для меня это повод вернуться к вопросу, как оценить технический долг. Прежде чем ускорять исправления, нужно решить, какие из них вообще нужны продукту. Sonar связывает риск именно с этим разрывом: изменений становится больше, чем команда успевает проверить. Источник: Sonar.
Аргумент «анализатор нашёл много замечаний» меня бы не убедил согласовать большой рефакторинг. Рефакторинг – изменение внутреннего устройства кода с сохранением его внешнего поведения. Его цель нужно уметь объяснить руководителю без экскурсии по всем файлам проекта.
Мартин Фаулер описывает «проценты» по техническому долгу как дополнительные усилия при развитии системы. Мне ближе такой взгляд, чем подсчёт некрасивых функций: он показывает, за какую работу бизнес вынужден платить снова. Источник: Technical Debt.
Предлагаю завести карточку на каждый участок, который команда хочет исправить. Не на каждое предупреждение инструмента.
| Поле карточки | Что записать |
|---|---|
| Участок и проблема | Где находится долг и какое устройство кода мешает работе |
| Наблюдаемое последствие | Что приходится повторять, что ломается или какую задачу нельзя выполнить |
| Подтверждение | Ссылки на задачи, изменения кода, разборы сбоев и результаты проверок |
| Частота обращений | Как часто участок меняли за выбранный период и зачем |
| Планы продукта | Какие согласованные задачи снова затронут этот участок |
| Повторные затраты | Время на обход проблемы, дополнительную проверку и переделки |
| Цена исправления | Анализ, изменение, тестирование, выпуск, наблюдение после запуска |
| Риск вмешательства | Что можно нарушить и как восстановить прежнюю работу |
| Решение и владелец | Исправляем, исследуем или откладываем; кто отвечает за пересмотр |
Заполнять её лучше вместе: инженер объясняет устройство системы, руководитель продукта подтверждает, что предстоит менять. Иначе можно добросовестно посчитать долг в модуле, который скоро перестанет использоваться. Расчёт будет аккуратный, пользы от него – мало.
Для повторных затрат я предлагаю простой расчёт: ожидаемое число изменений на согласованном горизонте умножить на лишние трудозатраты при каждом изменении. Затем сравнить результат с полной оценкой исправления. Это опора для решения, бухгалтерской точности здесь ждать не стоит.
Самая спорная величина здесь – «лишнее время». Фаулер предлагает сравнивать фактические усилия с оценкой работы в системе без соответствующей проблемы. Но тут же оговаривается: второе состояние воображаемое, поэтому объективно измерить его трудно. Источник: Estimated Interest.
Вот почему я прошу отделять факт от предположения. «В прошлой задаче пришлось проверять несколько реализаций одного правила» – наблюдение, которое можно подтвердить. «После объединения логики все задачи станут быстрее» – гипотеза. К ней нужен диапазон ожидаемой экономии с объяснением, откуда он взялся.
Не записывайте в долг всё время, которое ушло на задачу. Уточнение новых требований или ожидание решения заказчика могут задерживать выпуск, но исправление структуры кода этих задержек не уберёт. Если подтверждений пока нет, карточка должна вести к исследованию. Переписывать код ещё рано.
Что исправлять первым, а что можно отложить
Мой критерий жёсткий: в первую очередь исправляем то, что создаёт неприемлемый риск или мешает уже выбранному направлению развития продукта. Красота внутреннего устройства сама по себе не даёт задаче права пройти без очереди.
Ждать аварии при этом не нужно. Если команда не может проверить последствия изменения в критическом участке, отсутствие известных сбоев ещё ничего не доказывает. Сначала придётся разобраться, чем мы рискуем.
Для разговора об очереди я использовал бы такую таблицу. Это предложенная схема принятия решений, а не описание конкретного проекта CRT.
| Ситуация | Приоритет | Ближайшее действие |
|---|---|---|
| Есть подтверждённый риск потери данных или нарушения критического сценария | Срочно оценить и ограничить риск | Определить безопасное исправление и способ проверки |
| Долг блокирует согласованную продуктовую задачу | До зависимой задачи | Выделить минимальную подготовительную работу |
| Часто меняемый участок требует повторных обходов и переделок | Ближайшее планирование | Сопоставить накопленные затраты с ценой исправления |
| Проблема выглядит серьёзной, но последствия неизвестны | Сначала исследование | Проверить зависимости и собрать свидетельства |
| Модуль стабилен, изменения не планируются, существенный риск не выявлен | Отложить с условием пересмотра | Назначить владельца и повод вернуться к решению |
Я бы не сводил эти строки к единому баллу. Возможная потеря данных и неудобство редактирования – слишком разные основания для решения. Среднее арифметическое легко спрячет риск, который руководитель должен увидеть отдельно.
В разборе Т1 архитектор Владислав Воячек предлагает учитывать стоимость как погашения, так и непогашения долга. Я бы вынес на разговор с бизнесом именно эту пару вопросов: сколько стоит исправить и что произойдёт, если оставить. Источник: Т1.
А что, если код старый и всем неприятен, но работает? Я за то, чтобы иногда оставлять его в покое. Фаулер тоже допускает такой выбор для редко затрагиваемых участков, где дополнительные затраты невелики. Источник: Technical Debt Quadrant.
Моя позиция перестаёт работать, если за видимой стабильностью скрываются неизвестные зависимости, есть существенный риск или продуктовые планы скоро потребуют вмешательства. Поэтому у решения «отложить» должен быть повод для пересмотра: перед изменением интеграции, при повторном сбое или при включении модуля в план развития. Запись «когда-нибудь перепишем» никого ни к чему не обязывает.
Почему поручение ИИ «почистить весь проект» ведёт в тупик
В материале Sonar описан характерный провал: агент решает локальную задачу, изменение проходит его собственные тесты, но нарушает архитектурные границы или требования эксплуатации, которых не было в контексте. Есть и другой сценарий: агент подхватывает хрупкие решения из существующего кода и повторяет их. Результат выглядит убедительно. За ним легко не заметить, что система осталась непонятой. Это перечисленные авторами режимы ошибок, а не кейсы CRT. Источник: разбор Sonar.
Поручение «исправь всё плохое» я считаю управленческим тупиком. Как вообще понять, что оно выполнено? Инженер получает набор изменений, но из задания неясно, какие последствия требовалось устранить и какое поведение сохранить.
Поэтому уменьшения числа предупреждений мне недостаточно, чтобы признать работу успешной. Нужно вернуться к карточке долга и проверить, исчезла ли описанная проблема: проще ли теперь внести нужное изменение, сохранился ли договорённый результат для пользователя и соседних систем.
Отдельно я бы выяснил, сколько изменений команда способна проверить. Ещё до старта нужно знать, кто прочитает код, кто разбирается в затронутых зависимостях и что делать, если тестов для нужного сценария нет. Нет ответов – сначала готовим проверку. Дополнительный код ведь не устранит эту неизвестность.
Как поручить исправление ИИ-инженеру
В CRT роль AI Software Engineer предполагает ответственность за задачу от анализа до запуска. Для меня разработка с ИИ-агентами имеет смысл именно при таком распределении ролей: инженер задаёт границы работы и отвечает за то, что принято в эксплуатацию.
С конкретной карточкой долга я предлагаю работать в таком порядке.
- Описать результат. Какое повторное действие должно исчезнуть или какой риск требуется снизить. По формулировке «улучшить качество кода» работу не примешь.
- Зафиксировать границы. Какие модули разрешено менять, какие интерфейсы и зависимости нужно сохранить. Соседние улучшения записывать отдельно.
- Подготовить проверку текущего поведения. Выбрать значимые сценарии, входные данные и ожидаемые результаты. С неизвестным поведением сначала разобраться; обнаруженный дефект согласовать как отдельное изменение.
- Поручить ИИ ограниченную работу. Инженер проверяет предложенный план и изменения, затем сверяет результат с исходной задачей.
- Проверить последствия. Помимо автоматических проверок, проследить, как изменение повлияло на соседние компоненты и затронутые пользовательские сценарии.
- Выпустить изменение и проверить эффект. Заранее предусмотреть, как восстановить прежнюю работу, и вернуться к исходным показателям при следующих сопоставимых задачах.
Условная постановка может звучать так: «Собрать повторяющееся правило расчёта в одном месте, сохранив результаты для согласованных входных данных. Формат ответа внешним системам не менять. Подтвердить результат проверками вызывающих компонентов». Это пример задания (не история клиентского проекта).
Техническая приёмка и проверка экономического смысла здесь происходят в разное время. При выпуске можно подтвердить, что поведение сохранилось, а согласованное изменение выполнено. Снижение трудозатрат станет видно позже, когда команда снова возьмётся за сопоставимую работу. До этого экономия остаётся ожиданием.
Для меня разработка приложений с помощью ИИ не отменяет расстояния между «код готов» и «задача бизнеса решена». Если после рефакторинга повторные затраты остались, придётся пересмотреть гипотезу. Возможно, команда исправила участок, который бросался в глаза, а задержки возникали совсем в другом месте.
Вопросы и ответы
Можно ли оценить технический долг одним числом?
Одно число удобно для отчётности, но недостаточно для выбора работ. Оценку технического долга лучше показывать через трудозатраты на исправление, повторные затраты при изменениях и риски. Рядом нужно указывать горизонт планирования и степень уверенности в оценке.
Достаточно ли отчёта статического анализатора?
Статический анализатор проверяет код по заданным правилам и помогает находить кандидатов на исправление. Приоритет требует дополнительного контекста: последствий для продукта, частоты изменений и планов команды. Число замечаний не заменяет карточку проблемы.
Нужно ли устранять весь технический долг перед новой разработкой?
Исправлять весь долг перед развитием продукта необязательно. Имеет смысл выделить проблемы, которые блокируют запланированные задачи или создают неприемлемый риск. Стабильные участки можно отложить, зафиксировав условия пересмотра решения.
Как принять рефакторинг, выполненный с помощью ИИ?
Проверить границы изменений, согласованное поведение системы и последствия для зависимых компонентов. Ответственный инженер должен предъявить результаты проверок и порядок восстановления работы. Само наличие сгенерированного кода или успешный ответ модели приёмкой не считается.
Что делать
Я бы начал с участка, на который команда регулярно жалуется: собрал подтверждения повторных затрат, заполнил карточку и договорился, по чему будем принимать работу. Если последствия пока неизвестны, первое задание – исследовать их. В формате AI Software Engineer CRT инженер ведёт такую задачу от анализа до работающего решения и отвечает за проверку и запуск.
Обсудить задачу
