Технический долг как метафора программной инженерии

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

Технический долг (также известный как долг кодинга) — это метафора программной инженерии, обозначающая накопленные в программном коде или архитектуре программного решения проблемы, связанные с пренебрежением к качеству при разработке программного обеспечения и вызывающие дополнительные затраты труда в будущем.

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

Сам по себе плохой код не всегда является техническим долгом, так как ущерб ("проценты по долгу") появляются из-за необходимости изменения кода.

Термин технический долг используется в первую очередь по отношению к разработке программного обеспечения, но он также может быть применён и к другим сферам проектирования. Иногда термин используется неправильно, обозначая более не поддерживаемый код (англ. legacy code), который является некачественным и написанный кем-то другим.

Общие причины технического долга:

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

Продолжение развития проекта без оглядки на последствия может в будущем увеличить стоимость «погашения задолженности». Погашение долга происходит посредством простого выполнения незавершённой работы.

Накопление технического долга является основной причиной превышения сроков выполнения проектов. Трудно оценить, сколько именно работы необходимо выполнить для погашения долга. Неопределённое количество незавершённой работы добавляется в проект с каждым изменением. Сроки «горят», когда в проекте приходит понимание того, что есть ещё гораздо больше незавершённой работы (долга), чем времени для её завершения. Чтобы иметь предсказуемые графики выпуска, команда разработчиков должна ограничить количество выполняемой работы до такого, которое позволило бы минимизировать объёмы незавершённой ранее работы (долга).

Пока программа постоянно меняется, её сложность увеличивается, ее структура ухудшается. И это связано с увеличением технического долга. Создание временного кода, - это влезание в долги. Небольшой долг ускоряет разработку до тех пор, но он должен быть своевременно погашен путем переписывании. Опасность возникает, когда долг не погашен. Каждая минута, потраченная на не-совсем-правильный код, учитывается как процент по долгу.

При накоплении технического долга растет энтропия ПО, а рефакторинг может привести к сокращению энтропии ПО.

Для справки. Энтропия ПО. Второй закон термодинамики основан на том, что беспорядок в замкнутой системе не может уменьшаться, он может только оставаться неизменным или расти. Мерой беспорядка является энтропия. Этот закон справедлив и для программных систем. При модификации системы её беспорядок может только расти, это и называется энтропия ПО.

Мэнни Леман предложил несколько законов в части описания проблем создания ПО, из которых стоит упомянуть следующие два:

• Используемая компьютерная программа будет модифицирована;
• Когда компьютерная программа модифицируется, её сложность увеличивается, при условии что никто этому не препятствует.