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

Заполнить bugtracker задачами технического долга недостаточно: чтобы продать бизнесу технический долг, нужно понимать “процент выплат” по каждой из задач. Встает вопрос "что важнее": вычистить лог, чтобы саппорт быстрее с ним разбирался, добавить метрики в Prometheus, чтобы DCO видело падение производительности, доделать честную многопоточность для хороших циферок масштабируемости и производительности или отрефакторить старую подсистему.

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