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

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

Традиционной метафоре строительства в нашей профессии соответствует термин «конструирование»[58]. Как часто мы им пользуемся для описания своих действий? По моим наблюдениям, довольно часто. Все начинается с детства. Если вы из моего поколения, то ребенком, наверное, играли с конструкторами – ну а представители поколения X, вероятно, помнят свои экзерсисы с Lego. Обиходное понятие «конструирование программного обеспечения» вполне доходчиво обозначает повседневную деятельность программиста. Попробуем проанализировать эту метафору в буквальном смысле и объяснить, что значит дополнять приложения новыми характеристиками. Можно ли надстроить небоскреб дополнительными десятью этажами и при этом пребывать в уверенности, что фундамент их выдержит? Мне так не кажется; надеюсь, что и вы придерживаетесь моего мнения. Придется обратиться к еще одной метафоре – садоводству. Разбивая сад и выращивая его, вы, естественно, время от времени выкорчевываете одни растения и высаживаете другие. В своей книге о прагматическом программировании Эндрю Хант (Andrew Hunt) и Дэвид Томас (David Thomas) высказываются об этой метафоре следующим образом:

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

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

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

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

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

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