Что такое технический долг? Как его погасить (с примерами)

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

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

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

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

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

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

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

Больше никаких разрозненных подразделений: оптимизация организационной структуры для более тесного взаимодействия между командами

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

Получайте аналитическую информацию

Технический долг — это плохо?

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

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

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

Существует четыре причины технического долга, которые называют квадрантами технического долга. Четыре квадранта технического долга, введённые Мартином Фаулером, включают безрассудный, осмотрительный, преднамеренный и непреднамеренный. Эти квадранты помогают команде и заинтересованным сторонам понять, какие типы долга могут накапливаться в кодовой базе.

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

1. Разумный и преднамеренный: решение о быстрой поставке и устранении последствий позже приводит к разумному и преднамеренному долгу. Этот тип долга чаще всего используется, когда ставки в проекте ПО относительно низкие, а преимущества быстрой поставки перевешивают риск. Это сознательный компромисс, позволяющий быстрее вывести продукт на рынок.

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

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

4. Безрассудный и непреднамеренный: безрассудный и непреднамеренный долг возникает, когда команда пытается создать лучший код, не обладая необходимыми для этого знаниями. Зачастую команда не осознает, какие ошибки совершает. Это может привести к уязвимостям и проблемам с обслуживанием.

Команды выбирают преднамеренный технический долг ради быстрого выпуска продукта, в то время как непреднамеренный долг является случайным — он возникает после внедрения. Это различие лучше всего описал инженер-программист Стив Макконнелл, рассказывая о двух основных типах технического долга. Понимание этих квадрантов является ключом к управлению долгом в течение циклов разработки. Давайте рассмотрим каждый из них, чтобы лучше понять суть.  

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

Стив Макконнелл, главный инженер-программист Construx Software, предположил, что существует два типа технического долга: преднамеренный и непреднамеренный.

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

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

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

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

• Целенаправленный краткосрочный долг: включает в себя индивидуально идентифицируемые горячие клавиши. 

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

• Долгосрочный долг: долгосрочный долг возникает заранее по стратегическим причинам, например, для соблюдения дедлайна. В эту категорию часто попадают автоматизация и рефакторинг.

Как видите, срок погашения зависит от типа долга.

2. Непреднамеренный технический долг

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

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

Как измерить технический долг

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

Показатели и инструменты

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

Лучшие практики оценки

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

Как погасить технический долг

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

Это пошаговое руководство поможет вам погасить технический долг и создать более прозрачное рабочее место в отношении долговой нагрузки. 

Шаг 1. Определите и расставьте приоритеты в отношении технического долга 

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

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

• Если вы используете Scrum, ведите список долгов как часть своего продуктового бэклога Scrum, рассматривая каждый долг как «стори» Scrum и оценивая усилия и график погашения каждого долга так же, как вы оцениваете другие стори в Scrum.

Шаг 2. Рефакторинг и оптимизация кода

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

Шаг 3. Установите стандарты кодирования и лучшие практики

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

Шаг 4. Постоянный контроль и устранение новых долгов

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

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

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

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

• Описание: команда выбирает фреймворк, который быстро настраивается, но имеет известные проблемы с производительностью и минимальный функционал.

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

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

Пример 2. Непреднамеренный технический долг

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

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

• Долг: хотя команда обнаружила большинство проблем, недопонимание между штатными сотрудниками и временной поддержкой привело к тому, что некоторые ошибки в коде были упущены из виду. Это означает, что команде придётся отлаживать эти ошибки после запуска. 

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

Управляйте техническим долгом с прозрачностью

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

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

Больше никаких разрозненных подразделений: оптимизация организационной структуры для более тесного взаимодействия между командами

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

Получайте аналитическую информацию

Часто задаваемые вопросы: технический долг

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

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

Технический долг — это хорошо или плохо?

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

Каковы распространённые причины технического долга?

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

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

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

Как предотвратить технический долг?

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