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

Технический долг (также известен как проектный долг[1] или же кодовый долг, но также может быть связано с другими техническими разработками) - это концепция в разработка программного обеспечения Это отражает предполагаемую стоимость дополнительных доработок, вызванных выбором простого (ограниченного) решения сейчас вместо использования лучшего подхода, который потребовал бы больше времени.[2]

Как и с денежным долг,[3] если технический долг не погашен, он может накапливать «проценты», что затрудняет внесение изменений. Неадекватный технический долг увеличивается программная энтропия. Как и денежный долг, технический долг не обязательно является плохим явлением, и иногда (например, в качестве доказательства концепции) требуется для продвижения проектов. С другой стороны, некоторые эксперты утверждают, что метафора «технического долга» имеет тенденцию минимизировать воздействие, что приводит к недостаточной приоритизации необходимой работы по его исправлению.[4][5]

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

Причины

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

  • Постоянная разработка, длительная серия усовершенствований проекта со временем делает старые решения неоптимальными.
  • Недостаточное предварительное определение, когда требования все еще определяются во время разработки, разработка начинается до того, как будет выполнено какое-либо проектирование. Это сделано для экономии времени, но позже часто приходится переделывать.
  • Давление со стороны бизнеса, когда бизнес рассматривает возможность выпуска чего-либо раньше, чем необходимые изменения будут завершены, приводит к накоплению технической задолженности, включающей эти незавершенные изменения.[6]:4[7]:22
  • Отсутствие процесса или понимания, когда компании слепы к концепции технического долга и принимают решения, не учитывая последствий.
  • Компоненты с сильной связью, функции которых не выполняются модульный, программное обеспечение недостаточно гибкое, чтобы адаптироваться к изменениям в потребностях бизнеса.
  • Отсутствие набора тестов, поощряющее быстрые и рискованные лейкопластырь исправление ошибок.
  • Отсутствие документации, где код создается без сопроводительной документации. Работа по созданию документации представляет собой долг.[6]
  • Отсутствие сотрудничества, когда в организации не делятся знаниями и страдает эффективность бизнеса, или младшие разработчики не получают должного наставничества.
  • Параллельная разработка в нескольких ветвях приводит к возникновению технической задолженности из-за работы, необходимой для объединения изменений в единую исходную базу. Чем больше изменений будет сделано по отдельности, тем больше будет долга.
  • Отложенный рефакторинг - по мере развития требований к проекту может стать ясно, что части кода стали неэффективными или трудными для редактирования и должны быть переработаны для поддержки будущих требований. Чем дольше откладывается рефакторинг и чем больше кода добавляется, тем больше задолженность.[7]:29
  • Отсутствие соответствия стандартам, при котором игнорируются стандартные функции, структуры и технологии. В конце концов наступит интеграция со стандартами, и это раньше будет стоить меньше (аналогично «отложенному рефакторингу»).[6]:7
  • Незнание, когда разработчик не умеет писать элегантный код.[7]
  • Отсутствие права собственности, когда работа по аутсорсингу программного обеспечения приводит к тому, что для рефакторинг или переписать внешний код.
  • Плохое технологическое лидерство, когда плохо продуманные команды передаются по вертикали.
  • Изменения спецификаций в последнюю минуту, они могут распространиться на весь проект, но нет времени или бюджета, чтобы довести их до конца с документацией и проверками.

Типы

В дискуссионном блоге "Квадрант технического долга"[8] Мартин Фаулер различает четыре типа долга на основе двух дихотомических категорий: первая категория - безрассудная или расчетливая, вторая - преднамеренная или непреднамеренная.

Квадранты технического долга
БезрассудныйРасчетливый

Преднамеренный
 		«У нас нет времени на дизайн»«Мы должны отправить товар сейчас и разобраться с последствиями (позже)»

Непреднамеренный
 		"Что наслоение?"«Теперь мы знаем, как нам следовало это сделать»

Обслуживание или погашение технического долга

Кенни Рубин использует следующие категории статуса:[9]

  • Произошедшая техническая задолженность - задолженность, о существовании которой группа разработчиков не подозревала, пока она не была обнаружена в ходе обычной работы над продуктом. Например, команда добавляет новую функцию к продукту и при этом понимает, что обходной путь был встроен в код много лет назад кем-то, кто давно ушел.
  • Известный технический долг - долг, который известен команде разработчиков и стал видимым с помощью одного из ранее обсужденных подходов.
  • Целевой технический долг - известная задолженность, предназначенная для обслуживания командой разработчиков.

Последствия

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

Накопление технического долга - одна из основных причин срыва проектов в срок.[нужна цитата ] Трудно точно оценить, сколько работы нужно для погашения долга. Для каждого инициированного изменения в проект передается неопределенный объем незавершенной работы. Крайний срок пропускается, когда проект понимает, что незавершенной работы (долга) больше, чем времени для ее завершения. Чтобы иметь предсказуемые графики выпуска, команда разработчиков должна ограничить объем незавершенной работы, чтобы сохранить объем незавершенная работа (или долг) всегда небольшая.[нужна цитата ]

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

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

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

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

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

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

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

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

Написав о разработке PHP в 2014 году, Джунаде Али сказал:

Цена неисполнения этого технического долга очевидна; в конечном итоге стоимость предоставления функциональности станет настолько низкой, что хорошо спроектированный конкурентный программный продукт может легко обогнать плохо спроектированное программное обеспечение с точки зрения функций. По моему опыту, плохо спроектированное программное обеспечение также может привести к более напряженной работе инженеров, что, в свою очередь, приведет к увеличению оттока персонала (что, в свою очередь, влияет на затраты и производительность при предоставлении функций). Кроме того, из-за сложности данной кодовой базы возможность точно оценить работу также исчезнет. В тех случаях, когда агентства по разработке берут плату за отдельные функции, размер прибыли за доставку кода в конечном итоге ухудшится.

— Джунаде Али пишет в Освоение шаблонов проектирования PHP[13]

Грейди Буч сравнивает, насколько развивающиеся города похожи на развивающиеся программно-интенсивные системы и как отсутствие рефакторинга может привести к техническому долгу.

«Концепция технического долга является центральной для понимания сил, которые воздействуют на системы, поскольку она часто объясняет, где, как и почему система подвергается стрессу. В городах ремонт инфраструктуры часто откладывается, и вносятся постепенные изменения, а не смелые. . То же самое и в системах с интенсивным программным обеспечением. Пользователи страдают от последствий капризной сложности, отложенных улучшений и недостаточных дополнительных изменений; разработчики, которые развивают такие системы, страдают от того, что никогда не смогут написать качественный код, потому что они всегда пытаясь наверстать упущенное ".[1]

— Грейди Буч, 2014

В программное обеспечение с открытым исходным кодом, откладывание отправки локальных изменений в проект разведки и добычи является формой технического долга.[нужна цитата ]

Смотрите также

Рекомендации

  1. ^ а б Сурьянараяна, Гириш (ноябрь 2014 г.). Рефакторинг для разработки программного обеспечения (1-е изд.). Морган Кауфманн. п. 258. ISBN  978-0128013977.
  2. ^ «Определение термина« Технический долг »(плюс некоторая справочная информация и« объяснение »)». Техопедия. Получено 11 августа, 2016.
  3. ^ Оллман, Эрик (май 2012 г.). «Управление техническим долгом». Коммуникации ACM. 55 (5): 50–55. Дои:10.1145/2160718.2160733.
  4. ^ Джеффрис, Рон. «Технический долг - плохая метафора или худшая метафора?». Архивировано из оригинал 11 ноября 2015 г.. Получено 10 ноября, 2015.
  5. ^ Кнесек, Дуг. «Предотвращение кризиса технической задолженности». Получено 7 апреля, 2016.
  6. ^ а б c Гириш Сурьянараяна; Ганеш Самартйам; Тушар Шарма (11 ноября 2014 г.). Рефакторинг для разработки программного обеспечения: управление техническим долгом. Elsevier Science. п. 3. ISBN  978-0-12-801646-6.
  7. ^ а б c Крис Стерлинг (10 декабря 2010 г.). Управление долгом за программное обеспечение: создание для неизбежных изменений (Adobe Reader). Эддисон-Уэсли Профессионал. п. 17. ISBN  978-0-321-70055-1.
  8. ^ Фаулер, Мартин. «Квадрант технической задолженности». Получено 20 ноября 2014.
  9. ^ Рубин, Кеннет (2013), Essential Scrum. Практическое руководство по самому популярному гибкому процессу, Эддисон-Уэсли, стр. 155, ISBN  978-0-13-704329-3
  10. ^ Леман, ММ (1996). «Возвращение к законам эволюции программного обеспечения». EWSPT '96 Труды 5-го Европейского семинара по технологии обработки программного обеспечения: 108–124. Получено 19 ноября 2014.
  11. ^ Уорд Каннингем (1992-03-26). «Система управления портфелем WyCash». Получено 2008-09-26.
  12. ^ Кериевский, Джошуа (2004). Рефакторинг под шаблоны. ISBN  978-0-321-21335-8.
  13. ^ Али, Джунаде (сентябрь 2016 г.). Освоение шаблонов проектирования PHP | PACKT Книги (1-е изд.). Бирмингем, Англия, Великобритания: Packt Publishing Limited. п. 11. ISBN  978-1-78588-713-0. Получено 11 декабря 2017.

внешняя ссылка