Технический долг. С этим термином приходится иметь дело большинству программистов, активно работающих по специальности. У многих его упоминание может даже вызвать головную боль, а также неприятные ощущения в других частях тела, которые появляются всякий раз, когда в ходе работы над проектом имеешь дело с техническим долгом.
Поэтому сегодня поговорим о техническом долге (ТД): что это такое, как он появляется, какие виды технического долга бывают, и как им эффективно управлять.
Что такое технический долг?
Впрочем, сначала разберемся с терминологией. Технический долг — это метафора программной инженерии, обозначающая накопленные в программном коде или архитектуре проблемы, связанные с пренебрежением к качеству при разработке программного обеспечения и вызывающие дополнительные затраты труда в будущем. Такое определение техническому долгу дает Википедия. Если выражаться проще, технический долг — это результат применения упрощенных и краткосрочных решений в разработке, которые позже приводят к постоянно растущим (если, конечно, долг не “погасить”) расходам средств и времени на последующую доработку, переписывание кода или поддержку продукта в существующем виде. В мире рядовых программистов технический долг — это одна из разновидностей негативной кармы, демотиватор и источник печали, который приходит как расплата за плохой код, использование костылей и “временные” (а на самом деле не очень) решения, которые помогают решать краткосрочные задачи и ускорять разработку “в кредит,” то есть за счет растущего клубка проблем в будущем. В ИТ-индустрии технический долг — это достаточно серьезная проблема. По данным одного из недавних исследований, компании по всему миру ежегодно тратят более $85 миллиардов в год только на работу над исправлениями некачественного кода. А всего на проекты, связанные с поддержкой устаревших систем и “плохого” программного обеспечения, уходит около $300 миллиардов в год. Это значительные цифры. Исследователи подсчитали, что если усилия всех разработчиков, которые работают с техническим долгом и его последствиями, перефокусировать на “правильную” разработку, это добавит к мировому ВВП около 3-х триллионов долларов в течение текущего десятилетия.Причины появления
Следует понимать, что технический долг — это не всегда плохо, так же, как и влезание в финансовые долги может быть позитивным, если вы, например, берете кредит на развитие бизнеса (или запуск стартапа). В случае с ТД, это приемлемо для быстро растущих компаний, которым нужно выпускать новые продукты или услуги оперативно и часто, чтобы оценивать их успешность и изучать потребности рынка, либо быстро захватывать новые ниши, например. Но, как и в случае с долгами финансовыми, с техническим долгом нужно быть осмотрительным и уметь им управлять, иначе могут появиться серьезные проблемы. Чем больше при разработке программного продукта накапливается технического долга, тем сильнее это может отразиться на компании, замедляя выпуск новых релизов, понижая мораль рядовых кодеров, на плечи которых ложится “содержание” такого долга, и увеличивая расходы, что в конечном счете может даже погубить компанию. Причинами возникновения технического долга, кроме благородного желания закончить продукт как можно скорее или порадовать юзеров новым релизом, часто служит плохой продукт-менеджмент, нереалистичные сроки или ресурсные ограничения, ну и конечно, кодерская лень вкупе с низкой квалификацией и непониманием ключевых принципов разработки тоже часто вносит в рост долга свою лепту. Часто бывает и так, что сами разработчики хорошо осведомлены о наличии и постоянном росте технического долга, но не имеют достаточно власти, чтобы это изменить, или не могут донести до руководства информацию о наличии такой проблемы и важности ее решения.
Классификация
Умышленный технический долг.
Появляется в тех случаях, когда разработчики осознанно выбирают не самое лучшее решение, потому что его проще и быстрее реализовать, что, в свою очередь, поможет оперативнее выпустить новый продукт на рынок.
“Иногда мы умышленно берем на себя технические долги, чтобы уменьшить время разработки. Если вы решаете пойти этим путем, принимайте во внимание не только то время, что удастся сэкономить при разработке, но и то, которое придется потратить потом, чтобы “погасить” такой долг. Кроме того, удостоверьтесь, что заинтересованные стороны [топ-менеджмент компании] знают о том, что такое решение неизбежно замедлит запуск других функций в дальнейшем,” — отметил Даг Льодден.
Подход к решению данного типа технического долга
Эксперт советует тщательно документировать такие случаи, чтобы вернуться к ним и исправить до тех пор, пока этот технический долг не затерялся, став неотъемлемой частью структуры проекта.
Случайный или возникший из-за устаревшей архитектуры проекта технический долг.
Также технический долг часто возникает со временем, из-за ошибок и недоработок на этапе создания архитектуры проекта. По мере развития систем и изменений к требованиям программных продуктов ошибки в дизайне проекта начинают становиться более явными, а добавление новых функций требует все больше времени и усилий. Здесь важную роль играет качество первоначальной архитектуры проекта — она должна быть одновременно простой и функциональной, тогда ее будет легче адаптировать к изменениям.
Подход к решению данного типа технического долга
Чтобы технический долг данного вида не накапливался и не превышал критических объемов, Даг Льодден рекомендует регулярно проводить рефакторинг — примерно раз в два года, в те периоды, когда система находится в устойчивом состоянии. Тимлиды и продакт-менеджеры должны выделять время на “погашение” такого рода технического долга, который возникает из-за архитектуры и часто меняющихся требований к проекту.
Технический долг, возникающий со временем.
Эксперт называет такой технический долг “долгогниющим.” Он накапливается со временем, когда компонент или система постепенно становятся все сложнее из-за множества постоянно добавляемых изменений. Часто это усугубляется, если над системой на разных этапах работают разные люди, которые не до конца понимают оригинальную архитектуру.
Подход к решению данного типа технического долга
Это единственный из трех типов технического долга, которого следует стараться избегать на постоянной основе, путем регулярного рефакторинга, говорит эксперт. В идеале команда разработчиков должна выделять время на то, чтобы досконально изучить архитектуру системы, с которой работает, даже в том случае, если изначально создавали ее другие люди. Понимание системы позволит постепенно улучшать и исправлять плохой код, не доводя проект до стадии “гниения.”
Решения для управления техническим долгом
Существует много вариантов эффективного управления техническим долгом, но все эксперты сходятся во мнении, что делать это надо обязательно, так как ТД является неотъемлемой частью практически любой разработки, а те компании, которые игнорируют его, на более поздних этапах неизменно сталкиваются с проблемами. Вот несколько эффективных решений и подходов к управлению техническим долгом для команды разработчиков.Выделять фиксированную долю рабочего времени на работу над техническим долгом.
Особенность технического долга в том, что на работу по его устранению никогда не находится времени (потому что всегда есть более приоритетные задачи), если не заниматься этим целенаправленно. Поэтому хорошим решением будет выделить на эти цели некий фиксированный процент рабочего времени — около 20-25%.
Делать это можно по-разному.
Работать над техническим долгом 1 день в неделю
Если выделять на работу над устранением ТД всей командой один день в неделю, это как раз будет около 20% от общего рабочего времени. Для некоторых команд такой подход работает просто отлично и, говорят, даже повышает мораль, ведь в этот конкретный день недели вся команда занимается решением проблем, которые достают их все остальное время разработки.
Посвящать работе над ТД каждую четвертую задачу
Такая система подходит тем командам, которые склонны разделять работу над проектом на примерно равномерные по времени и усилиям для их выполнения задачи. Если один из каждых четырех тасков посвящать “выплате” ТД, это будет занимать около четверти всего времени разработки. А введение такого подхода в качестве правила позволит убедиться, что кодеры не будут откладывать технический долг “на потом”.
Переходящая роль
Еще одним подходом к проблеме устранения технического долга будет назначать на данную задачу разных членов команды поочередно, чтобы равномерно распределить эту порой далеко не самую приятную работу среди членов коллектива. Количество разработчиков, назначенных заниматься “разгребанием” ТД, может быть разным — для команды из 4-5 человек будет достаточно одного, тогда как коллективы побольше могут назначать двух-трех. Но суть остается прежней — на работу над ТД должно уходить около 20-25% всех ресурсов и человеко-часов.
Правило бойскаутов.
Правило бойскаутов состоит в том, чтобы всегда оставлять туристический лагерь (стоянку для палаток) в лучшем состоянии, чем он был до их прихода, то есть убирать даже тот мусор, который был оставлен не ими. Этот принцип, как выяснили заокеанские кодеры, отлично подходит и для управления техническим долгом. Согласно данному правилу, все члены команды должны заниматься исправлением ТД каждый раз, когда сталкиваются с ним в том или ином виде. Конечно, это правило нужно применять разумно, чтобы время, которое уходит на исправление ТД, не превышало “разумные” 25-30% от общих временных ресурсов.
Приоритизация “дорогого” технического долга
Также эксперты в массе своей рекомендуют не забывать о том, что технический долг может различаться в том числе и по важности. Далеко не каждый тип ТД требует немедленного устранения, поэтому важно работать над классификацией разных видов технического долга и приоритезацией работы с ними соответственно. Проще говоря, прежде всего закрывать надо те долги, которые оказывают прямое влияние на скорость разработки продукта, будучи частью его базовой архитектуры. Такие долги являются самыми опасными, потому что ведут к появлению новых долгов, которые могут расти как снежный ком.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ