Альфапедия

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

редактировать
Концепция разработки программного обеспечения

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

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

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

Содержание

  • 1 Причины
  • 2 Типы
  • 3 Обслуживание или погашение технического долга
  • 4 Последствия
  • 5 См. Также
  • 6 Ссылки
  • 7 Внешние ссылки

Причины

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

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

Типы

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

Квадранты технической задолженности
БезрассудствоОсмотрительность
. Умышленное.«У нас нет времени на проектирование»«Мы должны отправить товар сейчас и разобраться с последствиями ( позже) "
. Случайно." Что такое наслоение? "«Теперь мы знаем, как мы должны были это сделать»

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

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

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

Последствия

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

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

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

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

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

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

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

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

В своем тексте 2004 года Refactorin g в «Шаблоны» представляет сопоставимый аргумент относительно затрат, связанных с архитектурной небрежностью, которую он описывает как «проектный долг».

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

В статье о разработке PHP в 2014 году говорилось:

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

— пишет в статье «Освоение шаблонов проектирования PHP»

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

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

— Грэди Буч, 2014

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

См. Также

Ссылки

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

Внешние ссылки

Последняя правка сделана 2021-06-09 11:51:29
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте