Долги проектированию

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

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

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

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

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

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

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

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

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

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

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

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

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

  • http:// Kosta

    отличный блог у вас. Удивляет малая активность комментаторов — неужели никто не читает?

  • http:// igor

    Спасибо. Видимо комментировать нечего 🙂

  • http:// Тишецкий

    Да просто нету здесь никого, вон алекса ранк ниже 9М.

    Счётчик поставь и всё увидишь.

  • http:// igor

    Да я и так знаю трафик, нафиг мне счетчик, у меня логи есть.

    Темы просто специфичные, мало кого интересуют на самом деле.

  • http:// And

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

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

  • http://artamonov.ru splix

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

  • http:// Evgenic

    Миллионный раз все на туже тему, теперь и на русском языке. Понятно, проще некуда. Но к сожелению в нашей стрене 99% команд влезают в эти долги сразу и по ухи. Лучше дела обстоят только в проектах, где коллапс настает на следующее утро. И еще замеченная тенденция. Чем проще язык программирования, тем больше долги. У сишников и паскалей чаше присутствует проектирование. А вот в java и скриптах мной не встречено ни разу, что наводит на мысль на нелучшим выбори этих средств для больших проектов. Оговорюсь что мои наблюдения касаются моего окружения невыходящего за пределы СНГ. Знаком с одним финским проектом, я просто ох*ел от того как у них обстоит это дело. Все мои изыскания по поводу пойти по пути грамотного проектирования и просто изучения КАК ЭТО ДЕЛАТЬ натыкаются на непроходимые дебри КУСТАРЩИНЫ, царящей на просторах СНГ. А откуда у нас появятся эти технологии и культура программинга вцелом. ЛАБАЕМ КАК УМЕЕМ и не беда что учились на физиков, строителей и прочих непрограммеров. Придет время, накопится опыт, тогда мож и перейдет количество в качество. Или китайци вытеснят нас из этого бизнеса.

  • http:// Александр Нуйкин

    Всегда интересовался дизайном.

    В своих личных, а также командных проектах применял «предварительное» проектирование — результат не самый лучший. После прочтения «TDD» Кент Бека и «Рефакторинг» Мартина Фаулера — все встало на свои места. Важным считаю применение паттернов. Кончено опыт геморроя с предварительным дизайном тоже пригодился...

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

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