Русская Википедия:Технический долг
Технический долг (также известный как долг кодинга) — это метафора программной инженерии, обозначающая накопленные в программном коде или архитектуре проблемы, связанные с пренебрежением к качеству при разработке программного обеспечения и вызывающие дополнительные затраты труда в будущем. Технический долг обычно незаметен для конечных пользователей продукта, а связан с недостатками в сопровождаемости, тестируемости, понятности, модифицируемости, переносимости. По аналогии с финансовым долгом, технический долг может обрастать «процентами» — усложнением (или даже невозможностью) продолжения разработки, дополнительным временем, которое разработчики потратят на изменение программного продукта, исправление ошибок, сопровождение и т. п. Хотя увеличение технического долга как правило негативно влияет на будущее проекта, оно может быть и сознательным, компромиссным решением, продиктованным сложившимися обстоятельствами.
Сам по себе плохой код не всегда является техническим долгом, так как ущерб («проценты по долгу») появляются из-за необходимости изменения кода со временемШаблон:Sfn.
Термин технический долг используется в первую очередь по отношению к разработке программного обеспечения, но он также может быть применён и к другим сферам проектирования.
Иногда термин используется неправильно, обозначая более не поддерживаемый код (Шаблон:Lang-en), который является некачественным и написан кем-то другимШаблон:Sfn.
Причины
Общие причины технического долга (может быть несколько)[1]:
- Давление бизнеса, когда бизнесу требуется выпустить что-то раньше, чем будут сделаны все необходимые изменения, может вылиться в накопление технического долга.
- Отсутствие процессов или понимания, когда бизнес не имеет понятия о техническом долге и принимает решения без учёта последствий.
- Сильное зацепление компонентов, когда декомпозиция системы выполнена неправильно или недостаточно гибко, чтобы адаптироваться к изменениям бизнес-потребностей.
- Отсутствие тестов — ускоренная разработка и применение быстрых рискованных исправлений («костылей») для исправления ошибок.
- Отсутствие документации, когда код создаётся без необходимой сопроводительной документации. Работа, необходимая для создания вспомогательной документации, — это также долг, который должен быть погашен.
- Отсутствие взаимодействия между командами, неэффективное управление знаниями в организации. Например, отсутствие наставничества в команде разработчиков.
- Отложенный рефакторинг — чем дольше задерживается рефакторинг, и чем больше написано кода, использующего текущее состояние проекта, тем больше накапливается технический долг, который нужно "погасить" при следующем рефакторинге.
- Отсутствие опыта, когда разработчики просто не умеют проектировать программные системы или писать качественный код.
Последствия
«Процентные платежи» появляются как при локальной разработке, так и при отсутствии технической поддержки со стороны других разработчиков проекта. Продолжение развития проекта может в будущем увеличить стоимость работ по «погашению долга». Погашение технического долга происходит посредством простого выполнения незавершённой работы.
Накопление технического долга является основной причиной срыва сроков выполнения проектов. Трудно оценить, сколько именно работы необходимо выполнить для погашения долга. Неопределённое количество незавершённой работы добавляется в проект с каждым изменением. Сроки «горят», когда в проекте приходит понимание того, что есть ещё гораздо больше незавершённой работы (долга), чем времени для её завершения. Чтобы иметь предсказуемые графики выпуска, команда разработчиков должна ограничить объем выполняемой работы до такого уровня, который позволил бы минимизировать объём незавершённой ранее работы (технического долга).
В то время как закон увеличения сложности Мэнни Лемана уже доказывал, что постоянное развитие программ увеличивает их сложность и ухудшает структуру, пока ведётся работа над ними, Уорд Каннингем впервые провёл сравнение между технической сложностью и долгом в отчёте за 1992 год:
В своей статье от 2004 года «Рефакторинг с использованием шаблонов» Джошуа Кериевски представляет в качестве аргумента сравнение расходов, потраченных на решение вопросов, связанных с архитектурной халатностью, которую он описывает как «долг структуры»[2].
Действия, которые могут быть отложены, включают документацию, написание тестов, уделение внимания комментариям с пометкой «TODO», борьбе с компилятором, а также предупреждениям по статическому анализу кода. Другие случаи технического долга включают базу знаний, которая не распространяется внутри организации, и код, который является слишком запутанным, чтобы его было легко изменять.
В программном обеспечении с открытым исходным кодом откладывание отправки локальных изменений в основной проект является техническим долгомШаблон:Нет АИ.
См. также
- Фактор автобуса, фактор кирпича (Bus factor)
- Большой комок грязи (Big ball of mud)
- Деградация данных Шаблон:Ref-en
- TODO, FIXME, XXX Шаблон:Ref-en
- Энтропия ПО
- SQALE Шаблон:Ref-en
Примечания
Ссылки
- Уорд объясняет метафору Задолженности, видео от Уорда Каннингема Шаблон:Ref-en
- СТехническимДолгом Интернет-сообщество по обсуждению технического долга Шаблон:Ref-en
- Стив Макконнелл обсуждает технический долг Шаблон:Ref-en
- Технический Долг от Мартина Фаулера Блики Шаблон:Ref-en
- Диалоги с Энди Лестер под названием Шаблон:Wayback «Вылезайте из технического долга немедленно!» Шаблон:Ref-en
- Законы Лемана Шаблон:Ref-en
- Общество с ограниченной ответственностью WIP — обсуждаются методы по предотвращению образования технического долга Шаблон:Ref-en
- Вебинар по управлению технической задолженностью от Стива Макконнелла Шаблон:Ref-en
Литература
