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

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

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

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

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

Причины

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

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

Последствия

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

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

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

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

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

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

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

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

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

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

См. также

Примечания
  1. Tornhill, 2018, Questioning Technical Debt.
  2. Чебанов. Человеческий фактор в разработке программного обеспечения: психологические и математические аспекты. habr.com (2 декабря 2014). Дата обращения: 21 ноября 2019.
  3. 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.
  4. Каннингем, Уорд. The WyCash Portfolio Management System (26 марта 1992). Дата обращения: 26 сентября 2008.
  5. Kerievsky, Joshua. Refactoring to Patterns (неопр.). — 2004. — ISBN 0-321-21335-1.

Ссылки

Литература
  • Adam Tornhill. Software Design X-Rays. — Pragmatic Bookshelf, 2018. — ISBN 9781680502725.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.