Technical Debt – это определение, которое появилось в разработке достаточно давно, но активно о нем заговорили с 2008-2009 года. С тех пор на каждой конференции есть доклады на эту тему и теперь только ленивый не знает что это такое.

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

Вчера я посмотрел отличное выступление на эту тему:

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

Финансовый долг имеет совершенно другую структуру. Вы заняли у кого-то денег, вы должны отдать ему их через какое-то время. Но совершенно необязательно это должны быть те же самые купюры или заработанные именно вами. В конце концов, вы можете занять у кого-то еще и отдать долг первому кредитору. И продолжить жить в долг, но как бы “освежив” его. Вы можете плюнуть на все и продать что-то, тут же получив сумму денег для покрытия долга. Так просто НЕ РАБОТАЕТ для технического долга.

Мне очень понравилась одна цепочка рассуждений в данном докладе. Что мы подразумеваем под “выплатой” технического долга? То, что мы приведем код, дизайн или архитектурное решение в адекватное состояние через некоторое время. Естественно, без изменения бизнес функциональности самой системы. Это называется рефакторинг. Но всем известно, что для проведения рефакторинга нужно иметь возможность убедиться в том, что поведение не изменилось и все работает как раньше. Чтобы это сделать, нужны тесты. Но мы их не писали, писали мало или очень коряво в тот момент, когда накапливали технический долг. А это лишает нас возможности его “выплатить” либо приводит к экспоненциальному росту стоимости такой “выплаты”.

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

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

Хотите обсудить эту тему в кругу компетентных специалистов? Приходите на конференцию XP Days Ukraine 2016, которая состоится в Киеве 11-12 ноября.