Игорь Артамонов

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

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

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

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

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

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

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

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

Иногда сложно увидеть долг проектированию, но если вы встретите нижеуказанные проблемы, то вы уже увязли:

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

Чтобы не залезть глубоко в долги старайтесь больше внимания уделять следующему:

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

На основе:
«Design Debt«, Software Profitability, February 2004, by Jim Shore