Дж.Ханк Рейнвотер - Как пасти котов. Наставление для программистов, руководящих другими программистами

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

Чтобы соответствовать потребностям бизнеса XXI века, мы должны построить органичную методику разработки программных продуктов.

Метафора садоводства, к тому же, выражает различие между органическим и синтетическим. Все органическое выращивается; синтетические же объекты собираются из конструируемых компонентов. Действительно, конструируя компоненты, мы делаем их синтетическими по самой природе. Однако та среда, в которой их предполагается выращивать, должна выводить целое за рамки суммы компонентов. Кроме того, она должна предусматривать возможность адаптации к изменяющимся коммерческим требованиям и к технологической эволюции.

Итак, пытаясь усвоить материал, который я излагаю в дальнейшем, не забывайте о биологии и старайтесь не зацикливаться на аналогиях со строительной индустрией. Функции метафор ограничены – они просто-напросто помогают применить абстрактные понятия в условиях рутинной технической деятельности. Нельзя писать код, исходя из метафоры. В этом процессе без деталей проектного решения не обойтись. С другой стороны, все эти детали в совокупности формируют образец. А вот образец уже можно рассматривать метафорически, анализируя степень его применимости к решению бизнес-задач. Вы ведь еще не забыли, как важно для нас думать? Штудируя мою книгу, вы должны были уже уяснить, что главное в нашей работе – мыслить. Мыслить широко и ни в коем случае не поверхностно. Никогда не забывайте этот принцип – он вам пригодится.

За последнее десятилетие появилось множество работ – как фундаментальных, так и прикладных, – доказывающих необходимость применения в процессе разработки программных средств качественной архитектуры. Исследователи, специализирующиеся в этой области, указывают на то, что огромное количество проектов приложений заканчиваются неудачей именно из-за пренебрежения архитектурными вопросами [60] Рекомендую в этом контексте ознакомиться с работами апологетов позитивных и негативных эталонов, например с трудами Брауна (Вroun) и других исследователей, чьи публикации перечислены в библиографии. . В результате выполнения таких проектов, как правило, получаются «прямолинейные» системы. Их последующая адаптация к изменяющимся коммерческим требованиям осуществляется с большими трудностями, поскольку предполагает выделение значительных временных, трудовых и интеллектуальных ресурсов.

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

Создание архитектуры – это активный творческий процесс, который отнюдь не ограничивается сидением за клавиатурой, фиксацией коммерческих требований и реализацией компонентов, которые способны эти требования удовлетворить, в коде. В процессе работы над архитектурой вам придется абстрагироваться от своих механистических обязанностей и максимально углубиться в задачу, которую предстоит решить. Спору нет – во многих случаях решение оказывается вполне механистическим, то есть чисто программным. И тем не менее, если вы не разберетесь в задачах, стоящих перед своей компанией, обеспечить продуктам длительное и продуктивное существование вам, скорее всего, не удастся. Марк и Лора Сьюелл (Marc & Laura Sewell) в своей работе о роли архитекторов перечисляют ряд важнейших действий, которые должны предшествовать составлению любого проектного плана [61] Marc Т. Sewell and Laura М. Sewell, The Software Architect's Profession (Upper Saddle River, NJ: Prentice Hall, 2002), p. 68. . С точки зрения этих авторов, любой архитектор должен:

• в совершенстве владеть искусством выслушивания, опрашивания и наблюдения;

• хорошо разбираться в предметной области клиента – будь то банковское обслуживание, деятельность государственных органов, образование, здравоохранение, розничная торговля или скачки;

• получить стратегическое представление о деятельности предприятия клиента, не ограничиваясь тактическим или рабочим обзором его деятельности;

• иметь комплексные познания в технологической области – для того чтобы при разработке архитектурного плана суметь учесть все без исключения варианты стратегических решений;

• наладить конструктивное взаимодействие с клиентом и специалистом, ответственным за конструирование;

• уяснить видение вопроса клиентом и согласованное с ним проектное решение, следить за их неукоснительным соблюдением.

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

Архитектор должен уметь решать эту проблему, имея в виду два важных понятия: проектные ограничения (design forces), которые обусловливают все решения, принимаемые относительно программных средств, и аналитические позиции (analysis viewpoints), позволяющие принимать решения в соответствии с проектными ограничениями.