Много говорилось о том, что технический долг — это мусор, какой он нехороший и вместе с тем неизбежный. Когда я готовил доклад по этой теме, то задался вопросом: а насколько он «нехороший» в цифрах? Мне показалось важным опереться на авторитетные источники в этом вопросе и показать, что стоит за этими рассуждениями, в чем именно выражается «плохость» технического долга.
Так что сразу предупреждаю: внутри много цифр. А еще будет улитка. Ну, и немножко поделюсь собственным опытом работы с техническим долгом. Куда же без этого, тема-то больная.
Меня зовут Сергей Мехоношин, я Android-разработчик мобильного банка Газпромбанка, а в целом в IT уже больше шести лет. Наша команда, как и многие другие, работает с техническим долгом — думаем, как лучше им управлять, как уменьшать и т. д. Ну, то есть мы за все хорошее против всего плохого.
Всем понятно, что работа с техническим кодом важна: если в команде нет системного подхода к этому процессу, то скорость разработки падает, растет количество ошибок, а продукт становится все более заторможенным. Но насколько вообще это все страшно? Может, мы переоцениваем важность работы с техдолгом? Чтобы разобраться с этим, я решил обратиться за помощью к улитке Дорофеева — здорово помогает заглянуть в суть вещей.
Что говорит улитка
Первая улитка, которую я сформулировал, получилась такой:
Улитка, версия № 1
Если в команде не сформирован процесс работы со своим техническим кодом, то временная стоимость задач будет увеличиваться на x%, потому что требуется больше времени (по сравнению с ситуацией, когда этот процесс есть), чтобы создавать новые фичи в коде, который был плохо написан или спроектирован.
Однако эта улитка не прошла проверку по чек-листу формулировки. В частности, нарушен пункт 9 — обоснование содержит тавтологию. Поэтому немного переформулируем.
Улитка, версия № 2
Если в команде не сформирован процесс работы со своим техническим долгом, то временная стоимость задач будет увеличиваться на x%, потому что качество, читаемость и уровень проектирования кода ниже, а количество ошибок выше по сравнению с ситуацией, когда команда работает с техническим долгом.
Эта формулировка звучит логичнее, но чтобы она работала, нужно проверить, действительно ли эти зависимости существуют. Из формулировки вытекают несколько вопросов:
1. Какая взаимосвязь между отсутствием процесса и появлением технического долга?
2. Действительно ли качество, читаемост�� и уровень проектирования кода выше у команд, которые работают с техническим долгом?
3. Насколько выше?
4. Что за величина x — насколько реально увеличивается временная стоимость задач?
5. Действительно ли количество ошибок в коде меньше у команд, которые активно работают с техническим долгом?
6. Насколько меньше?
Покопавшись в личном опыте, поискав исследования, связанные с культурой разработки и техническим долгом, я смог найти более-менее, но твердую основу для ответа на выше заданные вопросы. Дальше делюсь с вами тем, что мне удалось найти.
Вопрос № 1: связь между отсутствием процесса и появлением долга
Сначала — немного личного опыта. Сразу скажу, что при точной оценке задачи, когда бизнес дает разработчику с высокой экспертизой достаточно времени, вероятность появления технического долга возможна, но минимальна. Это как раз та ситуация, в которой, на мой взгляд, техдолг возникать не должен. Произойти это может только по неопытности программиста.
Но жизнь хаотична, бизнес часто вынужден быстро реагировать на неожиданные ситуации и гнаться за возможностями, чтобы получить как можно больше прибыли или, наоборот, избежать потери денег. Так появляются «горящие» задачи.
Горящие задачи всегда нужно сделать здесь и сейчас. Весь фокус на скорость, а не на хорошую проектировку и написание кода. Именно в таких условиях и появляется технический долг — когда приходится делать плохо, потому что важно сделать хоть что-то, что будет криво да косо, но работать.
Примеры таких ситуаций:
Нужно резко показать начальству функции приложения, которые еще даже не готовы.
Сезонные акции и скидки. Вроде бы каждый раз они в одно и то же время, но часто почему-то становятся неожиданностью.
Участие в конкурсах. Markswebb, например, ежегодно оценивает мобильные банки по сотням параметров — от скорости переводов до удобства интерфейса. Попасть в топ или подняться на пару строчек — вопрос репутации, так что перед очередной волной исследования команды часто бросаются «докручивать» функции в авральном режиме.
Надо уже завтра обогнать конкурентов, а послезавтра обойти еще на один круг.
Получается, что совсем без технического долга не обойтись, так как жизнь создает новые вызовы бизнесу каждый день. И без процесса работы с техническим долгом он будет накапливаться в виде костылей в коде. Разработчики не возвращаются к «временным» решениям, и они становятся постоянными.
Во всей истории с неизбежностью техдолга важно, я считаю, чтобы был процесс работы с ним. И здесь стоит обратиться к тому, как в Google формулируют отношение к долгу. Приведу вывод из статьи про технический долг в компании — Defining, Measuring, and Managing Technical Debt:
That’s not to say we have no technical debt at Google <…> but zero technical debt is not the goal anyway <…>. Technical debt isn’t unequivocally a bad thing, after all. Just like financial debt, technical debt is one component of a strategy for trading off velocity and (some form of) quality or completeness.
«Это не значит, что у Google нет технического долга <…>, но нулевой технический долг и вовсе не цель <…>. В конце концов, технический долг — это не так уж и плохо. Как и финансовый долг, технический долг — это один из компонентов стратегии, которая позволяет найти компромисс между скоростью (в той или иной форме) и качеством или полнотой».
Другими словами, техдолг — не зло, а плата за гибкость. Главное — управлять им, а не делать вид, что его нет.
Вопросы № 2 и 3: качество, читаемость и уровень проектирования кода
Если принять, что техдолг неизбежен и без процесса работы с ним он накапливается, логично предположить: чем выше долг, тем ниже качество кода.
И тогда выведем две характеристики кода:
1. Код с высоким качеством — тестируемый, хорошо читаемый и структурированный. Будем считать, что обязательное условие кода с высоким качеством — работа с техническим долгом.
2. Код с низким качеством содержит много дефектов и костылей, имеет плохую мод��льность. Появляется там, где технический код не обрабатывается системно.
Чтобы ответить на вопрос, насколько качество кода выше у команд, которые работают с техническим долгом, нужно определиться с метриками и единицами измерения. За условную единицу можно взять время, потраченное на написание кода. Отвечать на вопрос будем с помощью исследований на тему влияния технического долга на количество дефектов и время разработки.
Сравнение исследований
В 2022 году исследователи провели ресерч Code Red: The Business Impact of Code Quality: они проанализировали 39 собственных кодовых баз из различных областей с помощью инструмента CodeScene, основанного на анализе исходного кода, данных системы контроля версий и информации о проблемах из Jira.
Что показало исследование:
решение проблем в файлах с низким качеством кода требует на 124% больше времени;
в худших случаях задачи решаются в 9 раз дольше.
Чтобы два раза не вставать, приведу сразу результаты еще нескольких исследований:
По данным Chalmers University of Technology, разработчики тратят в среднем 23% своего времени на преодоление технического долга. Основные потери времени происходят из-за дополнительного тестирования и необходимости работы с устаревшим кодом.
Опрос Sourcery.ai показал, что команды с высоким уровнем технического долга тратят почти на 50% больше времени на исправление ошибок и понимание существующего кода.
Еще одно исследование — от SEI (Software Engineering Institute) — показало, что рефакторинг трех проблемных областей кода обеспечил 295% возврата инвестиций в первый год и сэкономил 41,35 человеко-месяцев усилий в год.
То есть команды, которые постоянно работают с техническим долгом, действительно тратят меньше времени на разработку — и качество их кода выше.
Вопрос № 4: величина x
Как мы уже увидели из исследования Code Red и Chalmers и Sourcery.ai, решение проблем в коде низкого качества требует ощутимо больше времени. Конкретнее: время на выполнение задач при высоком техдолге увеличивается на 23–124%, а в худших случаях — до 9 раз. Это и есть величина x — реальная цена накопленного долга, выраженная в часах и днях разработки.
Вопросы № 5 и 6: количество ошибок
Как следует из исследования Code Red: The Business Impact of Code Quality, файлы с низким качеством кода содержат в 15 раз больше дефектов, чем файлы с высоким качеством.
Исследователи из University of Technology Chalmers добавляют еще один штрих: технический долг демотивирует разработчиков и снижает концентрацию, а это, в свою очередь, косвенно повышает количество багов.
Отвечая на вопросы улитки
Подытоживая, сообщу, как каждый вопрос был решен:
1. Какая взаимосвязь между отсутствием процесса и появлением технического долга?
Технический долг неизбежен: он возникает из-за бизнес-приоритетов, ограниченного времени и «горящих» задач. Без процесса работы с ним долг накапливается, превращая временные решения в постоянные.
2. Действительно ли качество, читаемость и уровень проектирования кода выше у команд, которые работают с техническим долгом?
Да. Системная работа с долгом повышает качество кода. Это подтверждают исследования.
3. Насколько выше?
Разница выражается в скорости работы: решение задач в чистом коде занимает на 23–124 % меньше времени.
4. Что за величина x — насколько реально увеличивается временная стоимость задач?
По данным исследований Code Red, Chalmers University и Sourcery.ai, время на выполнение задач при высоком техдолге увеличивается на 23–124 %, а в крайних случаях — до 9 раз.
5. Действительно ли количество ошибок в коде меньше у команд, которые активно работают с техническим долгом?
Да. Исследования Code Red, Sourcery.ai и SEI показывают, что команды, которые рефакторят и управляют долгом, допускают значительно меньше дефектов.
6. Насколько меньше?
Количество ошибок в таких командах — в 15 раз ниже, чем у тех, кто техдолг игнорирует.
Все эти данные подтверждают улитку, которую я сформировал в самом начале.
Заключение
Вернемся к улитке, с которой все началось. Если команда не работает со своим техническим долгом системно, временная стоимость задач увеличивается на 23–124% (а в тяжелых случаях — до 9 раз), потому что качество и читаемость кода падают, а количество дефектов растет. До 15 раз по сравнению с «чистым» кодом.
В общем, техдолг работает как кредитная карта. Можно набрать три штуки и бояться открывать приложение банка, потому что там все очень плохо. А можно держать одну и точно знать, когда заканчивается льготный период и сколько закинуть до конца месяца, чтобы не переплачивать. Второй вариант, как показывает практика, сильно экономит нервы. И время. И деньги.
Использованные источники
• Defining, Measuring, and Managing Technical Debt (Google Research, 2023).
• Code Red: The Business Impact of Code Quality (2022).
• Chalmers University of Technology (2019).
• The Impact of Technical Debt (Sourcery.ai, 2022).
• Кейс-стади SEI (Software Engineering Institute) (2016).
• Chalmers University of Technology — влияние техдолга на мораль и продуктивность разработчиков (2020).
