В последнее время очень часто обсуждается тема технического долга. Делается много докладов, пишется много постов, рисуется много графиков и тд, и тп.

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

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

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

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

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

Давайте вспомним, что мы обычно понимаем под техническим долгом. Согласно классическому определению,данному Уордом Каннигемом (Ward Cunningham), технический долг - это разница между идеальным техническим решением и тем решением, которое принимается сейчас.

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

Получается, что мы может говорить о следующих видах долга:

• долг реализации
• технологический
• процессный
• долг компетенции

Долг реализации: сюда можно отнести то, что обычно и понимают под техническим долгом, на мой взгляд узко смотря на эту проблему. Приобрести этот долг можно и приняв неправильные архитектурные решения, и добавив “костыли” в коде, и упростив процесс тестирования оставив там только “успешные” сценарии. Сюда же добавим и невозможность рефакторить исходный код, которая вызвана отсутствием тестов, что зацикливает эту проблему и вводит в клинч, когда все больше времени требуется на добавление новых фичей, потому что постоянно умирают старые. Очень ярко это отражено в твите (18+), читайте комменты – это просто песня. Я прослезился. Или наоборот “рефакторится” все направо и налево, а проверяют все это тестировщики ручками.

Долг технологический приобретается через отказ от применения новшеств в языках, фреймворках, инструментах. У меня на глазах пример использования С++, когда часто можно наблюдать осторожность (мягко говоря) во внедрении С++11, когда отказываются от использования boost’a, когда продолжают писать свои мега-крутые “велосипеды” игнорируя open-source библиотеки. Все это приводит к замедлению разработки, снижению качества и даже к снижению мотивации у людей, потому что они используют “несвежие” инструменты.

В кабалу процессного долга можно попасть отказываясь или затягивая принятие решений по применению Continuous Integration, XP-практик. Отсутствие веры, желания, понимания важности этого всего приводит к тому, что эти задачи, как правило с нижайшим приоритетом, накапливаются в списке общих задач. Потому что у нас всегда есть суперсрочные и суперважные для продукта задачи. И как следствие, только для того чтобы просто понять, что свежесобранный сетап не работает, приходится тратить от 10 мин до N часов (зависит от навороченности продукта).