Технический долг

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

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

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

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

Основные правила

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

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

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

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

На что обратить внимание

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

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

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

Тестирование

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

Профилирование и мониторинг приложения

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

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

Наличие багтрекинговой системы

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

Наличие архитектурного анализа проекта

Узкое место в любом приложении – архитектура, многие проблемы с производительностью и надежностью программного обеспечения возникают из-за проблем в архитектуре. Эти проблемы не всегда заметны явно, поэтому следует периодически анализировать архитектуру и определять проблемные места.

Наличие перспективного анализа проекта

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

Контроль версионной актуальности и совместимости используемых решений

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

Устранение технического долга

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

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

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