Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2018

Проектирования больше нет?

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, но не имеющих базисных знаний и умений в предварительном проектировании. И пожалуй наиболее полезна статья тем, чьи знания, умения и опыт равноценны в обеих сферах, т.к. изложенные концепции позволят наиболее эффективно и гармонично использовать и сочетать все эти бесценные умения в вашей работе.


Posted by Vitalii Tsybulnyk on Wednesday, July 22, 2009 7:06 AM
Permalink | Comments (1) | Post RSSRSS comment feed

Comments (1) -

Vitalii Tsybulnyk Canada

Sunday, July 26, 2009 11:02 AM

Нет, всё-таки несколько самых моих любимых цитат я не могу не привести:

Для примера можно взять одного из технических лидеров компании "ThoughtWorks", по имени Дэйв Райс (Dave Rice). Дэйв уже давно работает в компании и заслужил неофициальную мантию технического лидера в проекте, над которым работает около пятидесяти человек. Что же означает его лидерство? В первую очередь, то, что он проводит большую часть времени с программистами. Он помогает тем, кому это необходимо, и старается быть рядом на случай, если его помощь понадобится. Интересно отметить, где располагается его рабочее место. Как заслуженный сотрудник компании, он мог бы выбрать любое помещение по своему желанию. Тем не менее, вот уже несколько месяцев, как Дэйв перебрался в комнату к программистам (в том самом стиле "war room", который превозносит ХР). Для него очень важно находиться вместе с разработчиками, потому что в этом случае он знает, что происходит, и всегда может протянуть руку помощи тем, кто находится в затруднении.

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

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

Add comment




  Country flag

b i u quote
Loading