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

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

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

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

На семинаре в Дагштуле, проведенном в 2016 году, технический долг был определен академическими и промышленными экспертами по этой теме следующим образом: «В системах с интенсивным программным обеспечением технический долг представляет собой совокупность конструкций проектирования или реализации, которые целесообразны в краткосрочной перспективе, но установлены создать технический контекст, который может сделать будущие изменения более дорогостоящими или невозможными. Технический долг представляет собой фактическое или условное обязательство, влияние которого ограничивается внутренними качествами системы, в первую очередь ремонтопригодностью и возможностью развития». ^[6]

Причины [ править ]

К распространенным причинам технического долга относятся:

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

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

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

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

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

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

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

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

«Поскольку развивающаяся программа постоянно меняется, ее сложность, отражающая ухудшение структуры, увеличивается, если не проводится работа по ее поддержанию или сокращению». ^[11]
— Меир Мэнни Леман , 1980 г.

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

«Выпуск первого кода — это все равно, что влезть в долги. Небольшой долг ускоряет разработку, пока он быстро окупается переписыванием… Опасность возникает тогда, когда долг не погашен. Каждая минута, потраченная на не совсем правильный код считается процентами по этому долгу. Целые инженерные организации могут быть остановлены из-за долгового бремени неконсолидированной реализации, объектно-ориентированной или какой-либо другой». ^[12]
— Уорд Каннингем , 1992 г.

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

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

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

Цена никогда не выплачивать этот технический долг очевидна; в конечном итоге затраты на предоставление функциональности станут настолько медленными, что хорошо спроектированному конкурентоспособному программному продукту будет легко обогнать плохо спроектированное программное обеспечение с точки зрения функций. По моему опыту, плохо спроектированное программное обеспечение может также привести к более напряженной работе инженеров, что, в свою очередь, приведет к увеличению оттока персонала (что, в свою очередь, влияет на затраты и производительность при предоставлении функций). Кроме того, из-за сложности конкретной кодовой базы также исчезнет возможность точно оценить работу. В тех случаях, когда агентства разработки взимают плату за каждую функцию, размер прибыли от доставки кода в конечном итоге ухудшится.
— Джунаде Али пишет в книге «Освоение шаблонов проектирования PHP». ^[14]

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

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

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

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

Запах кода (признаки низкого качества кода, которые могут способствовать возникновению технического долга)
Большой ком грязи
Фактор автобуса
Эскалация обязательств
Манумация
сверхинжиниринг
Дробовиковая хирургия
Энтропия программного обеспечения
Программное гниение
Хвосты спагетти
СКАЛЕ
Невозвратные затраты
ВСЕ, ФИКСМЕ, ХХХ

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

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

Внешние ссылки [ править ]

Уорд объясняет метафору долга , видео от Уорда Каннингема
OnTechnicalDebt Интернет-сообщество для обсуждения технического долга
Интервью экспертов по техническому долгу: Уорд Каннингем , Филипп КРУЧТЕН , Ипек ОЗКАЯ , Жан-Луи ЛЕТУЗИ
Стив МакКоннелл обсуждает технический долг
Технический долг от Мартина Фаулера Блики
Предотвращение кризиса «технического долга», Дуг Кнесек
«Вылезайте из технического долга прямо сейчас!» , выступление Энди Лестера
Закон Лемана
Вебинар «Управление техническим долгом», Стив МакКоннелл
Баунди, Дэвид , Рак программного обеспечения: семь признаков раннего предупреждения или здесь , Заметки по разработке программного обеспечения ACM SIGSOFT, Vol. 18 № 2 (апрель 1993 г.), Ассоциация вычислительной техники, Нью-Йорк, Нью-Йорк, США.
Технический долг: инвестируйте и предотвратите банкротство Колин Споул
Технические долги: все, что вам нужно знать
Что такое технический долг? из блога DeepSource

[Girish_2014-1] Jump up to: Перейти обратно: ^а ^б Сурьянараяна, Гириш (ноябрь 2014 г.). Рефакторинг для запахов дизайна программного обеспечения (1-е изд.). Морган Кауфманн. п. 258. ИСБН 978-0128013977 .

[2] «Определение термина «Технический долг» (плюс некоторая справочная информация и «объяснение»)» . Техопедия . Проверено 11 августа 2016 г.

[Managing_Technical_Debt-3] Оллман, Эрик (май 2012 г.). «Управление техническим долгом». Коммуникации АКМ . 55 (5): 50–55. дои : 10.1145/2160718.2160733 . S2CID 53246391 .

[Jeffries_2015-4] Джеффрис, Рон. «Технический долг – плохая метафора или худшая метафора?» . Архивировано из оригинала 11 ноября 2015 года . Проверено 10 ноября 2015 г.

[Knesek_2016-5] Кнесек, Дуг. «Предотвращение кризиса технического долга» . Проверено 7 апреля 2016 г.

[6] Авжериу, Париж; Крухтен, Филипп; Озкая, Ипек; Кэролайн, моряк (2016). «Управление техническим долгом в разработке программного обеспечения (семинар dagstuhl 16162)» (PDF) . Отчеты Дагштуля . 6 (4).

[:0-7] Jump up to: Перейти обратно: ^а ^б Риос, Николли; Спинола, Родриго Оливейра; Мендонса, Маноэль; Моряк, Кэролин (11 октября 2018 г.). «Наиболее распространенные причины и последствия технического долга: первые результаты глобального семейства промышленных исследований» . Материалы 12-го Международного симпозиума ACM/IEEE по эмпирической разработке программного обеспечения и измерениям . ЭСЕМ '18. Нью-Йорк, штат Нью-Йорк, США: Ассоциация вычислительной техники. стр. 1–10. дои : 10.1145/3239235.3268917 . ISBN 978-1-4503-5823-1 .

[SuryanarayanaSamarthyam2014-8] Jump up to: Перейти обратно: ^а ^б ^с Гириш Сурьянараяна; Ганеш Самартьям; Тушар Шарма (11 ноября 2014 г.). Рефакторинг для запахов проектирования программного обеспечения: управление техническим долгом . Эльзевир Наука. п. 3. ISBN 978-0-12-801646-6 .

[Sterling2010-9] Jump up to: Перейти обратно: ^а ^б ^с Крис Стерлинг (10 декабря 2010 г.). Управление долгом по программному обеспечению: создание неизбежных перемен (Adobe Reader) . Аддисон-Уэсли Профессионал. п. 17. ISBN 978-0-321-70055-1 .

[Essential_Scrum:_Velocity-10] Рубин, Кеннет (2013), Essential Scrum. Практическое руководство по самому популярному гибкому процессу , Аддисон-Уэсли, с. 155, ISBN 978-0-13-704329-3

[11] Леман, ММ (1996). «Возвращение к законам эволюции программного обеспечения» . EWSPT '96 Материалы 5-го Европейского семинара по технологиям разработки программного обеспечения : 108–124. ISBN 9783540617716 . Проверено 19 ноября 2014 г.

[oopsla92-12] Уорд Каннингем (26 марта 1992 г.). «Система управления портфелем WyCash» . Проверено 26 сентября 2008 г.

[rtp-13] Кериевский, Джошуа (2004). Рефакторинг в шаблоны . ISBN 978-0-321-21335-8 .

[14] Али, Джунаде (сентябрь 2016 г.). Освоение шаблонов проектирования PHP | ПАКТ Книги (1-е изд.). Бирмингем, Англия, Великобритания: Packt Publishing Limited. п. 11. ISBN 978-1-78588-713-0 . Проверено 11 декабря 2017 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]