Технический долг при разработке ПО

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

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

В этой статье от онлайн школы Foxminded основное внимание уделяется тому, technical debt что это, его различным типам, причинам, последствиям, техническому долгу в Agile и примерам технического долга. Ознакомьтесь с ним и получите все необходимые знания о том, как избежать технических обязательств.

Что такое технический долг?

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

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

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

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

Определение технического долга

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

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

Agile полагается на сокращение объема выпуска для обеспечения качественной работы вместо продвижения множества функций в выпуске. Существует технический долг, который пассивно создается, когда scrum-команда узнает больше о проблеме, которую она пытается решить.

Согласно руководству Scrum:

• Владелец продукта несет ответственность за максимизацию ценности и работы команды разработчиков.
• Журнал невыполненных требований продукта представляет собой единственный актив требований, над которым будет работать команда разработчиков, и он должен включать в себя все, что требуется для доступности продукта.
• Во время планирования спринта владелец продукта обсуждает элементы бэклога продукта, подходящие для достижения цели спринта.

Компания может предотвратить технический долг в agile путем:

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

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

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

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

FoxmindEd — это учебный центр с большим выбором направлений курсов для новичков и программистов с опытом!

Начинаете свой путь в IТ? Попробуйте курсы Start

Имеете базовые навыки программирования? Тогда вам на курсы Junior

Хотите углубить свои знания в IТ? У нас есть курсы Middle/Senior

Виды технического долга

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

Умышленный технический долг

В случае с инженерами они знают, что есть правильный и быстрый способ сделать что-то. Но, иногда команда намеренно делает что-то не так, потому что ей нужно быстро доставить продукт на рынок. Отсюда технический долг.

Случайный/устаревший технологический долг проектирования

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

Давний технический долг

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

Причины технического долга

Technical code debt обычно возникает, когда решения по проектированию и внедрению программного обеспечения противоречат бизнес-целям и действиям.

Технические долги могут быть вызваны:

• Давлением времени
• Слишком сложной технической конструкцией
• Плохим соответствием стандартам
• Отсутствием навыков
• Неоптимальным кодом
• Отложенным рефакторингом
• Недостаточным тестированием

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

Примеры технического долга

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

• Технический долг в самом коде

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

Тем не менее, разработчик может написать уродливый код или использовать длинные методы и множество временных переменных.

• Технический долг в документации

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

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

• Изменение дизайна системы без изменения организационной структуры

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

• Слишком мало или слишком много автоматических тестов

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

• Перерастание моделей баз данных

Рост означает большую энтропию в кодовой базе, что, в свою очередь, подразумевает увеличение технического долга. Это мучительно, поскольку остальная часть системы часто опирается на структуру модели. Изменение основы модели базы данных оказывает волновой эффект на всю систему, и решение этой проблемы редко сводится только к рефакторингу модели.

Вывод

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