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

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

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

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

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

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

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

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

Покончите с разобщённостью: оптимизируйте организационную структуру для более эффективного взаимодействия между подразделениями

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

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

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

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

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

Что приводит к возникновению технического долга?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как видите, тип накопленного долга определяет, сколько времени потребуется на его погашение.

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

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

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

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

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

Показатели и средства

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Покончите с разобщённостью: оптимизируйте организационную структуру для более эффективного взаимодействия между подразделениями

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

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

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

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

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

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

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

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

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

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

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

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

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