Martin Fowler (Мартин Фаулер) бесспорно является одним из самых уважаемых авторов в области современного проектирования и архитектуры программных продуктов. Его бестселлеры 'Refactoring: Improving the Design of Existing Code' и 'Patterns of Enterprise Application Architecture' - это, пожалуй, наиболее ценные книги, прочитанные мною за всю мою профессиональную жизнь.

Недавно мне в руки попала замечательная статья Мартина с броским названием 'Is Design Dead?' (в русском переводе "Проектирования больше нет?"), о которой сегодня и пойдёт речь.

Основная идея статьи - обсудить изменения в подходах к проектированию программных систем в связи с переходом к гибким (Agile) методологиям. Провокационное название статьи отражает тот факт, что многие Agile методологи (в первую очередь XP) преподносят дизайн системы как нечто возникающее эволюционно, в процессе непосредственного кодирования:

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

Фаулер, как выдающийся специалист в области проектирования, конечно же не соглашается с таким утверждением:

В большинстве случаев, эволюционное проектирование - это нечто ужасное. В конце концов, все равно вместо дизайна системы вы получаете просто набор из специфических решений, каждое из которых затрудняет дальнейшие изменения в программном коде. Часто это вообще нельзя считать дизайном (и, уж конечно, такой дизайн никак нельзя назвать хорошим). Как говорит Кент, дизайн существует для того, чтобы дать возможность оперативно вносить в систему любые изменения. Если дизайн плох, то такая возможность исчезает. В результате вы будете иметь дело с энтропией программного продукта, и со временем и без того плохой дизайн системы станет еще хуже. Теперь вам будет не только сложнее вносить в систему изменения, но и отыскивать и исправлять ошибки, которые начинают множиться с катастрофической быстротой. Все это - кошмар разработок в стиле "code and fix", когда с течением времени исправление ошибок обходится все дороже и дороже.

Однако одновременно являясь ярым приверженцем Agile и автором "библии" рефакторинга, Фаулер признаёт и рекламирует их эффективность:

В методологии XP имеется много спорных моментов. Одним из ключевых таких моментов является то, что она базируется на эволюционном, а не предварительном проектировании. В основе этого утверждения лежит кривая стоимости изменений в программном продукте. XP строится на предположении, что эту кривую можно сгладить до такой степени, чтобы можно было применять эволюционное проектирование. Такое сглаживание, с одной стороны, возникает при использовании методологии XP, а с другой, оно же в ней и используется. Это еще раз подчеркивает тесную взаимосвязь между практиками ХР: нельзя использовать те части методологии, которые предполагают существование сглаживания, не используя те практики, которые это сглаживание осуществляют. У практик, с помощью которых осуществляется сглаживание, есть множество составляющих. В основе всех их лежит Тестирование и Непрерывная интеграция. Именно надежность кода, которую обеспечивает тестирование, делает возможным все остальное в этой методологии. Подобный эффект имеет и рефакторинг.

В статье Фаулер пытается найти компромис, балланс между традиционными (и бесспорно необходимыми) методиками проектирования с одной стороны и Agile с другой:

Джим Хайсмит ... использует аналогию с обычными весами. На одной чаше лежит предварительное проектирование, на другой - рефакторинг. В более традиционных подходах к разработке ПО перевешивает предварительное проектирование, так как предполагается, что передумать вы не можете. Если же стоимость изменений снизится, то часть проектирования можно делать и на более поздних стадиях работы, в виде рефакторинга. Это вовсе не означает отказа от предварительного проектирования. Однако теперь можно говорить о существовании баланса между двумя подходами к проектированию, из которых можно выбрать наиболее подходящий. Все эти основополагающие практики (непрерывная интеграция, тестирование и рефакторинг) создают новую среду, в которой эволюционное проектирование выглядит вполне убедительно. Впрочем, мы еще не выяснили, где же у этих весов точка равновесия. Лично я уверен, что не смотря на поверхностное впечатление, методология ХР - это не просто тестирование, кодирование и рефакторинг. В ней найдется место и для предварительного проектирования. Частично оно производится еще до написания первой строчки кода, но большая его часть приходится на то время, которое предшествует реализации конкретной задачи в течение итерации. Впрочем, такая ситуация представляет собой новое соотношение сил между предварительным проектированием и рефакторингом.

Собственно, вся статья и посвящена нахожденю этого компромисса. Показывается полезность и органичность предварительного проектирования в XP, преимущества и критерии простого дизайна перед сложным при условии следования всем остальным практикам XP, показывается эффективное сосуществование принципа YAGNI ("You Aren't Going to Need It" - "Это вам не понадобится") и рефакторинга, применимость и ценность паттернов проектирования и даже UML в XP.

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