Посчитайте, во сколько техдолг обходится в неделю

1. Долг, плохой код и изменившиеся требования

Технический долг — сознательное решение сделать быстрее и хуже ради выгоды сейчас: успеть к 11.11 на Wildberries, показать демо, закрыть требование банка к сроку. У него есть дата, полученная выгода и проценты — плата, пока он не погашен. Плохой код написан плохо, потому что иначе не умели: выгоды не было, «мы ускорились тогда» сказать нельзя. Разница меняет приоритизацию:

1. У долга известна выгода. «Срезали три недели в марте, платим 6 часов в неделю с апреля» — разговор про сделку. У плохого кода такого аргумента нет, а выдуманный рушит доверие ко всему отчёту.
2. Долг гасится проектом, плохой код — процессом. У долга есть конец, он локализован в одном-двух модулях; плохой код размазан ровным слоем и лечится линтером и ревью. Строка «весь легаси 1С-интеграции» не закроется никогда и утянет реестр в свалку.

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

2. Инвентаризация: факты, а не мнения

Клонируй через git_clone, собирай в sandbox_bash. Сначала масштаб (git ls-files | wc -l, git log --oneline | wc -l) — иначе доли не с чем сравнивать.

2.1 Маркеры в коде с классификацией по возрасту

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

Режим отказа. blame даёт последнее касание строки, а не дату написания маркера: массовое переформатирование обнуляет возраст всей базы. Признак — у 90% маркеров одна дата; лечение — -w и --ignore-revs-file. Генерируемые каталоги исключай.

2.2 Отключённые тесты

Самый дешёвый в поиске и дорогой по последствиям вид долга: выглядит как покрытие, но им не является.

Грепом не ищется главное — наборы, исключённые на уровне пайплайна. Сверь по .gitlab-ci.yml / .github/workflows/*.yml, какие пути реально попадают в прогон: типичный случай — набор, который гоняется только вручную и падает месяцами. Порог: skip старше 90 дней — это удалённый тест, притворяющийся существующим.

2.3 Зависимости с известными уязвимостями

В отчёт идут три числа: сколько critical/high достижимы из твоего кода (пакет импортируется, а не висит транзитивно в dev-ветке); сколько мажорных версий отставания у прямых зависимостей; сколько пакетов без релизов больше двух лет — такие не обновляют, а заменяют, и это проект. При сборке через зеркало пакетов аудит обязан смотреть на тот же индекс.

2.4 Мёртвый код и расходящиеся дубликаты

Анализаторы ложно срабатывают на всём, что вызывается по имени: точки входа CLI, обработчики фреймворка, ORM-модели, реестры плагинов. Невидимая им разновидность — мёртвые фича-флаги: флаг, включённый на 100% полгода, это два пути, из которых один не исполняется, но оба поддерживаются.

Дублирование само по себе не долг — долг там, где копии разошлись: одна логика в трёх местах, а правки за год приходили в две. Третья копия однажды даст баг «на Ozon скидка считается, на Wildberries нет».

2.5 Хотспоты: частота изменений × доля багфиксов

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

Второй проход — только по коммитам-исправлениям. Что считается багфиксом, определи по конвенции этого репозитория: посмотри git log --pretty=format:'%s' | head -50, при conventional commits фильтруй ^fix, при русских сообщениях добавь исправ|починк|фикс|баг, при живом трекере — префикс bug-задач.

Ранг (фиксы² / правки) ставит выше файл с 40 правками и 20 фиксами, чем с 200 правками и теми же 20: во втором правки в основном плановые, в первом каждая вторая — тушение.

2.7 Долг в схеме БД и в данных — самый дорогой класс

Собирается запросами, не грепом. Ищи: колонки, которые код больше не пишет, а схема держит; text там, где значений конечное число (SELECT col, count(*) GROUP BY 1 даёт 5 значений на миллионе строк — инвариант есть, ограничения нет, и он уже где-то нарушен); отсутствующие внешние ключи (LEFT JOIN ... WHERE parent.id IS NULL); миграции, не применённые в базе.

Чинить схему в 3–10 раз дороже, чем код той же сложности, и разрыв растёт с числом строк: нужно окно обслуживания, откатить почти нельзя (вместе со схемой поехали данные), а ошибка не падает с трейсбеком, а тихо приезжает в отчёт клиенту.

3. Проценты: во что долг обходится в неделю

3.1 Что складывать

Бизнес отклоняет «модуль плохо написан» и обсуждает «стоит 68 000 ₽ в неделю, устранение 240 000 ₽, окупаемость 3,5 недели».

Упущенную функциональность оценивай только вместе с продуктом.

3.2 Формула и ставка

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

3.3 Разобранный пример: выгрузка остатков в 1С

• Ручной труд 2 × 0,5 ч = 1 ч/нед; инциденты 4 ч на двоих раз в месяц = 2 ч/нед; замедление (правка требует ручного прогона, +3 ч на задачу раз в две недели) = 1,5 ч/нед.
• Итого 4,5 ч/нед; при ставке 2 500 ₽/ч — 11 250 ₽/нед, около 585 000 ₽ в год. Переписать на очередь с идемпотентностью — 60 ч, то есть 150 000 ₽: окупаемость 13 недель.
• Отдельной строкой без денег: отмены бьют по рейтингу продавца, рейтинг влияет на выдачу. В часах не считается, но это самый сильный аргумент в разговоре.

4. Приоритизация по четырём проверяемым осям

4.1 Оси

1. Частота соприкосновения — из /tmp/churn.txt. Долг, который не трогают, процентов не начисляет.
2. Стоимость ошибки. Верх шкалы: деньги клиента и отчётность в госорганы (расчёт цен, платежи, НДС, маркировка, ЕГАИС). Середина: работа сотрудников встаёт. Низ: косметика и внутренние отчёты.
3. Блокирует ли новые задачи. Признак: в бэклоге есть задача, оценка которой содержит «сначала переделать X». Тогда это не долг, а предусловие, и оно поднимается выше всего.
4. Растёт ли сам по себе — см. 4.2.

4.2 Растущий долг против стабильного

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

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

4.3 Ранг и то, что вне ранга

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

5. Долг, который нельзя гасить постепенно

Часть долга не делится: половина миграции хуже её отсутствия. Признаки неделимости — смена формата хранения, замена библиотеки без прослойки, изменение контракта API с внешними потребителями (мобильное приложение, обмен с 1С), переезд на другую версию СУБД.

Планируется только отдельным проектом с четырьмя атрибутами: точка невозврата (отодвинуть как можно дальше); режим двойной записи или чтения (пока живут оба варианта, вы поддерживаете два кода — это и есть цена); критерий переключения (расхождение старого и нового пути ниже порога на реальном трафике неделю подряд); дата удаления старого пути. Нет хотя бы одного — «не начинать, пока не назначен критерий переключения».

Незавершённая миграция — самый дорогой вид долга: удваивает поддержку, и ни одна сторона не считается рабочей окончательно. Признак — два модуля одного назначения со словами new/v2/legacy в имени, живущие дольше полугода.

6. Когда долг правильно НЕ гасить

• Код перед выводом из эксплуатации. Модуль отключают в этом полугодии — вложения сгорят; дата вывода и есть причина отказа.
• Гипотеза не подтвердилась. Функциональностью пользуются десять человек в месяц: удалить её вместе с долгом, а не рефакторить. Решают цифры использования, не мнение.
• Зона заморожена. git log --since='18 months ago' -- <путь> | wc -l = 0: проценты нулевые, погашение — чистый расход.
• Окупаемость длиннее остаточного срока жизни системы: 14 месяцев у системы, которую меняют через год.
• Долг взят осознанно, срок не наступил. Обходной путь на сезон распродаж — нормальная сделка; ошибка не в том, что взяли, а в том, что не назначили дату возврата.

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

7. Стратегии погашения и их честная цена

Дефолт: связанный рефакторинг для хотспотов, отдельный проект для неделимого, явный список того, что не гасится.

8. Реестр, который не превращается в свалку

8.1 Порог входа и потолок

В реестр попадает элемент с четырьмя заполненными полями: путь, что сломается, сколько стоит в неделю (или честное «не считали»), растёт или стоит. Не заполняется — это ощущение, а ощущения не хранятся. Активных записей не больше 25: при переполнении поднимают порог входа, не потолок.

8.2 Правило устаревания записи

У каждой записи есть дата пересмотра: P0/P1 — 30 дней, P2 — 90, P3 — 180. Когда дата наступила, запись проходит один вопрос — «менялась ли зона с момента внесения?» (git log --since='<дата>' --oneline -- <путь> | wc -l). Ноль у P2/P3 — закрыть со статусом «не подтверждено». Ноль у P0/P1 — приоритет выставлен неверно, понизить. Правки были — обновить оценку и назначить новую дату. Просроченный дважды элемент удаляется: за него не взялись два цикла, это и есть решение «не делаем».

8.3 Где хранить

Реестр — через documents или файлом в репозитории, чтобы он ревьюился вместе с кодом. Решения «не гасим, потому что…» — в manage_memory: следующий аудит не должен переоткрывать закрытые вопросы. Согласованное погашение ставь через manage_task с путём и недельной ставкой.