Технический долг — это термин, описывающий код, который изжил себя, но не был удален из проекта.
Например, его можно использовать для описания кода, который был написан до того, как требования были полностью поняты, и обнаруживается, что его недостает, когда становится доступна дополнительная информация. Вместо того, чтобы переписывать код с нуля (что, вероятно, лучше в долгосрочной перспективе), разработчики часто обходят ограничения нестандартного кода (что может быть лучше в краткосрочной перспективе).
Другая форма — это код, который существует для реализации функции, которая больше не нужна. Отключение функции обычно требует удаления только одной строки кода, что делает сотни других строк устаревшими.
Технический долг — неизбежная часть любой развивающейся программной системы. Редко бывает целесообразно удалить мертвый код или переписать целый модуль в более эффективную версию, и у разработчиков редко хватает терпения провести анализ, необходимый для устранения всех долгов, даже если у них есть время.
Слишком большой технический долг затрудняет обновление программного обеспечения, что замедляет работу разработчиков. Однако трата чрезмерного количества времени на удаление долга также замедлит разработчиков. Следовательно, это то, чем разработчики должны управлять. При добавлении функций в проект и особенно при исправлении ошибок разработчики должны выделять дополнительное время для устранения части долга.
Когда скорость высока, менеджеры проектов должны подготовиться к неизбежным жалобам на слишком большое накопление долга и должны строить в период «замедления», поощряя разработчиков атаковать долг. Когда скорость низкая, было бы полезно определить, не связано ли это с накоплением долга. Если это так, то позвольте скорости еще больше замедлиться, чтобы дать разработчикам шанс атаковать накопленный долг.
Точное знание того, какой долг является приемлемым и какой долг является наиболее дорогостоящим, не является тем, что отрасль нашла способ количественной оценки. На сегодняшний день разработчики используют субъективные ощущения о состоянии кода, а не какие-либо жесткие показатели того, что слишком много, или когда слишком много времени тратится на устранение долгов.
На мой взгляд, иметь общие истории с названиями вроде «погасить долг» или «код рефакторинга» — ошибка. Это побуждает разработчиков искать способ убрать низко висящие фрукты. Но если разработчик жалуется на то, что с каким-то определенным модулем сложно работать, самое время создать историю, чтобы заменить этот конкретный модуль чем-то, что было лучше спроектировано. Кроме того, при определении сюжетных баллов разработчиков следует поощрять к тому, чтобы они учитывали, существует ли какой-либо уже существующий код, от которого зависит новая функция, который можно было бы использовать, и повышать баллы для истории, чтобы дать им возможность сделать это. Особенно это касается исправления ошибок. Ошибка в коде — отличный момент, чтобы понять, что модуль, содержащий ошибку, вероятно, имеет слишком много долгов, и разработчик должен подумать о том, чтобы сделать больше, чем просто заставить код снова работать.
