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

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

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

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

Причины[править | править вики-текст]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. 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.
  2. Каннингем, Уорд. The WyCash Portfolio Management System (26 марта 1992). Проверено 26 сентября 2008.
  3. Kerievsky Joshua. Refactoring to Patterns. — 2004. — ISBN 0-321-21335-1.

Ссылки[править | править вики-текст]