Технический долг

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

Иногда термин используется неправильно, обозначая более не поддерживаемый код (англ. legacy code), который является некачественным и написанный кем-то другим[1].

Причины[править | править код]

Общие причины технического долга (может быть несколько)[источник не указан 136 дней]:

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

Последствия[править | править код]

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

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

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

Меир Мэнни Леман, 1980

В то время как закон увеличения сложности Мэнни Лемана уже доказывал, что постоянное развитие программ увеличивает их сложность и ухудшает структуру, пока ведётся работа над ними, Уорд Каннингем впервые провёл сравнение между технической сложностью и долгом в отчёте за 1992 год:

Создание первого временного кода, - это как влезание в долги. Небольшой долг ускоряет разработку до тех пор, пока не будет своевременно оплачиваться в виде переписывания… Опасность возникает, когда долг не погашен. Каждая минута, потраченная на не-совсем-правильный код, учитывается в качестве процента по этому долгу. Целые инженерные организации могут быть привлечены к простою из-за долговой нагрузки неконсолидированной реализации, объектно-ориентированной или иной[3].

Каннингем, Уорд, 1992

В своей статье от 2004 года «Рефакторинг с использованием шаблонов» Джошуа Кериевски представляет в качестве аргумента сравнение расходов, потраченных на решение вопросов, связанных с архитектурной халатностью, которую он описывает как «долг структуры»[4].

Действия, которые могут быть отложены, включают документацию, написание тестов, уделение внимания «TODO» комментариям, борьбе с компилятором, а также предупреждениям по статическому анализу кода. Другие случаи технического долга включают базу знаний, которая не распространяется внутри организации, и код, который является слишком запутанным, чтобы его было легко изменять.

В программном обеспечении с открытым исходным кодом откладывание отправки локальных изменений в основной проект является техническим долгом.

См. также[править | править код]

Примечания[править | править код]

  1. 1 2 Tornhill, 2018, Questioning Technical Debt.
  2. Lehman, M. M. Programs, life cycles, and laws of software evolution (англ.) // Proceedings of the IEEE. — 1980. — Iss. 68. — No. 9. — P. 1060—1076. — DOI:10.1109/PROC.1980.11805.
  3. Каннингем, Уорд. The WyCash Portfolio Management System (26 марта 1992). Проверено 26 сентября 2008.
  4. Kerievsky, Joshua. Refactoring to Patterns. — 2004. — ISBN 0-321-21335-1.

Ссылки[править | править код]

Литература[править | править код]

  • Adam Tornhill. Software Design X-Rays. — Pragmatic Bookshelf, 2018. — ISBN 9781680502725.