Технический долг: причины, индикаторы, управление
Прежде чем перейти к сущности технического долга как категории из области разработки ПО, поговорим сперва о задолженности как финансовой категории, т.е. о кредите. И здесь следует вспомнить два принципа кредитования: возвратность и платность. Иными словами, любой кредит необходимо будет погасить, а сумма, подлежащая к уплате, включает в себя не только тело кредита (основной долг), но и проценты.
Что такое технический долг и как он возникает?
Но вернемся к теме технического долга. Чтобы определиться, что такое технический долг и как он возникает, пойдем от обратного и представим идеальный конвейер разработки программного обеспечения, функционирующий в идеальных условиях.
Что это означает? А это означает соблюдение следующих трех условий:
- Во-первых, команда разработчиков обладает высокой квалификацией и способна предоставить надежное архитектурное решение, учитывающее не только текущие требования и функционал, который нужно разработать сейчас, но и на перспективу.
- Во-вторых, код, который они создают, являются стабильным, чистым и понятным.
- В-третьих, команда обладает достаточным запасом времени и бюджета для проектирования, кодирования, сборки, тестирования и отладки решения с целью обеспечения высокого качества. Другими словами, команде не приходится работать на быстрых решениях, чтобы уложиться в заданные сроки или бюджеты.
Если все три условия
соблюдены, с техническим долгом вы не столкнетесь. Однако, если хотя бы одно из
этих условий нарушено, и отрицательные последствия низкого качества создаваемой
(или уже созданной) системы наблюдаются уже сейчас, на лицо технический долг. В принципе, можно
разделить все метрики технического долга на две группы: Показатели текущего наличия
проблем По сути, это маркеры,
которые показывают, что Вы уже платите проценты из-за наличия технического
долга. Здесь можно использовать следующие показатели: а) Скорость команды Наличие
устойчивого нисходящего тренда отклонения фактической скорости от плановых показателей
говорит о наличии узких мест, которые приходится преодолевать. б) Время цикла Во-первых,
речь идет о появлении устойчивого превышения фактических KPI над плановыми в отношении основного времени цикла (т.е. времени,
затрачиваемого непосредственно на разработку функционала приложения). Это означает,
что разработчикам требуется больше усилий для создания новых функций или обновления
существующих. Кроме того, в качестве индикатора существования технического
долга можно назвать увеличение дополнительного времени цикла (т.е. времени, затрачиваемого
на закрытие тикетов на исправление ошибок). в) Количество ошибок Планомерное
увеличение количества ошибок уровня P1-P3 в продакшене, при внесении каких-либо изменении в уже созданную
систему, а также в ходе прогресса проекта. Сигналы рисков возникновения
проблем в будущем Здесь речь идет о метриках,
которые можно расценивать как сигналы того, что в будущем могут возникнуть
проблемы. Эти метрики в основном касаются анализа кода и проверки его качества,
а также метрик, характеризующих качество непосредственно архитектурного решения: а) Цикломатическая сложность
— значение этой метрики, превышающее 10, как правило, означает, что система
слишком сложна; восходящая тенденция указывает на увеличение сложности проекта б) Глубина наследования —
значение, превышающее 5 указывает на слишком длинные пути; восходящая тенденция
указывает на увеличение сложности проекта и большую неопределенность в поведении
класса в) Зависимость классов — если
показатель имеет значение более 30, то это говорит о высоких зависимостях,
которые несут в себе риск увеличения сложности обслуживания такой системы г) Коэффициент
масштабируемости — значение, превышающее 1, указывает на плохое архитектурное
решение, требующее слишком много ресурсов для масштабирования. Говоря о техническом
долге в аналогии с банковским кредитом (и здесь вновь вспоминаем принципы
платности и возвратности), следует отметить, что все расходы, которые могут
возникнуть в результате его технического долга, можно разделить на две условные
категории: проценты и основная задолженность. Проценты Применительно к
техническому долгу, проценты — это те дополнительные расходы, которые приходится
нести с целью преодоления ограничений программы. Другими словами, речь идет об
адаптации новых функций к существующему в настоящее время несовершенному решению
без непосредственного устранения его ограничений. Самый простой пример: работая
над развитием приложения, тратится много времени для того, чтобы разобраться в
коде и понять его логику. Еще пример: вводятся определенные ограничения в
рамках работы функционала с целью снижения времени обработки команд. Основная задолженность Это те дополнительные
расходы, которые приходится нести непосредственно для устранения имеющихся ограничений
кода и архитектуры программы. Самый простой пример:
чтобы каждый раз не приходилось разбираться в грязном и запутанном коде, делаем
рефакторинг этого кода (приводим к единому стилю, ясности по переменным,
убираем излишние комментарии, добавляем там, где они действительно необходимы).
Другой пример: оптимизируем код так, чтобы повысить быстродействие программы в
целом и получить более высокую скорость обработки команд (да, код может стать
более длинным, но оно того стоит). Общая стратегия управления
техническим долгом Во-первых, следует осознавать,
что проценты придется выплачивать в любом случае. Во-вторых, коль скоро сумма процентов,
подлежащих к уплате, находится в прямой зависимости от суммы основного долга,
уменьшение последней неизменно приведет к уменьшения первой. Иными словами, если уже
есть какие-то проценты к выплате, вероятно, следует начать погашение основного
долга прямо сейчас. Таким образом, стратегия
управления техническим долгом — это комплекс мероприятий, направленных на внутреннего
качества программы. На первый взгляд, именно
выплата процентов дает видимый результат. Да, потратив определенную сумму на обхождение
препятствий при разработке новой функции, вы все же в итоге получаете
приложение с увеличенным функционалом. Однако, если подсчитать,
сколько придется переплачивать за эти видимые результаты сейчас и в будущем,
вполне вероятно, реализация мероприятий по устранению технического долга является
более рациональным решением. В общем виде, стратегия управления
техническим долгом может быть описана следующим образом: Да, потратив
определенную сумму на рефакторинг, вы получаете приложение с тем же самым набором
функций, и нужны новые бюджеты для того, чтобы расширить функционал. Однако, заплатив,
условно, рубль сейчас, вы экономите два рубля в будущем. Разве это не отлично?!
Индикаторы технического долга
Управление техническим долгом