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

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

Путем анализа параметров надежности, безопасности. сопровождаемости, дублирования, покрытия, сложности, документирования

внешний аудит, автоматизация отчетов, код–ревью, непрерывная инспекция.

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

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

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

На самом деле, само понятие технического долга представляет из себя метафору. Ее придумал Уорд Каннингем. Эта метафора приводит сравнение с кредитом. Процентом по кредиту в данной модели является дополнительное время на внесение изменений, а выплата — это переписывание кода. Чисто технически можно даже рассчитать стоимость технического долга путем умножения времени, затраченного на решение проблем, на стоимость работы проектировщика (программиста).

Частота «чистки» кода – вещь индивидуальная. Так, можно потратить 2 дня на чистку модульной структуры, три – для функции. Т.е. выбор в пользу первого. Однако все меняется, если число функций увеличится.

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

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

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

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

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

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

Тем не менее, есть способы, позволяющие на начальном этапе предотвратить скопление долга. Добиться этого можно благодаря использованию таких инструментов, как: единоразовые прототипы MVP с незаметной миграцией пользователей с прототипов на стабильную часть, подтверждённые гипотезы, создание доступной (гибкой) для изменений архитектуры, применение облачных серверов, четкие инструкции в работе команд. Залог успеха – это постоянный мониторинг трендов проектирования и верно выбранный технический директор.

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

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

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

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

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

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

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

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

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

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

• Игнорирование в надежде, что все итак будет продолжать работать в штатном режиме (если что–то ломается, то переписывают с нуля).

Исходя из выбранного способа применяется один из четырёх способов управления техническим долгом:

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

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

Проверка разработчиками (код–ревью). Несмотря на меньшую затратность данного метода в денежном выражении, в данном способе управления техническим долгом человеческий фактор играет еще большую роль. Это живой инструмент, который позволяет не только увидеть баги, но и «учиться на ошибках». Дополнительное преимущество в том, что сам программист понимает логику работы. На практике же все эти плюсы могут быть убиты тем, что код–ревью может делать человек с недостаточной компетентностью.

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

Рассмотрим методы устранения технического долга.

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

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

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

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

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