Как пасти котов. Наставление для программистов, руководящих другими программистами
Шрифт:
Итак, пытаясь усвоить материал, который я излагаю в дальнейшем, не забывайте о биологии и старайтесь не зацикливаться на аналогиях со строительной индустрией. Функции метафор ограничены – они просто-напросто помогают применить абстрактные понятия в условиях рутинной технической деятельности. Нельзя писать код, исходя из метафоры. В этом процессе без деталей проектного решения не обойтись. С другой стороны, все эти детали в совокупности формируют образец. А вот образец уже можно рассматривать метафорически, анализируя степень его применимости к решению бизнес-задач. Вы ведь еще не забыли, как важно для нас думать? Штудируя мою книгу, вы должны были уже уяснить, что главное в нашей работе – мыслить. Мыслить широко и ни в коем случае не поверхностно. Никогда не забывайте этот принцип – он вам пригодится.
Примат архитектуры
За
60
Рекомендую в этом контексте ознакомиться с работами апологетов позитивных и негативных эталонов, например с трудами Брауна (Вroun) и других исследователей, чьи публикации перечислены в библиографии.
Занимаясь проектированием той или иной системы, вы должны уделять первоочередное внимание рискам. Каким видам рисков? Во-первых, риску ухудшения позиций компании на рынке, возникающему, когда в существующий продукт вследствие конкуренции приходится вносить новые непредусмотренные изначально черты; риску неумеренного усложнения процесса сопровождения продуктов, возникающему вследствие жесткой взаимозависимости компонентов-подсистем или негибкости их конфигурации. Еще один вид рисков заключается в неоправданной сложности продукта на верхних уровнях архитектуры. Это обстоятельство чрезвычайно усложняет задачу кодировщиков, не принимавших участия в процессе создания системы, но вынужденных выискивать способы исправления базовых компонентов. Все перечисленные проблемы имеют непосредственное отношение к временным и финансовым затратам, которые ваш начальник, естественно, желает сократить.
Создание архитектуры – это активный творческий процесс, который отнюдь не ограничивается сидением за клавиатурой, фиксацией коммерческих требований и реализацией компонентов, которые способны эти требования удовлетворить, в коде. В процессе работы над архитектурой вам придется абстрагироваться от своих механистических обязанностей и максимально углубиться в задачу, которую предстоит решить. Спору нет – во многих случаях решение оказывается вполне механистическим, то есть чисто программным. И тем не менее, если вы не разберетесь в задачах, стоящих перед своей компанией, обеспечить продуктам длительное и продуктивное существование вам, скорее всего, не удастся. Марк и Лора Сьюелл (Marc & Laura Sewell) в своей работе о роли архитекторов перечисляют ряд важнейших действий, которые должны предшествовать составлению любого проектного плана [61] . С точки зрения этих авторов, любой архитектор должен:
61
Marc Т. Sewell and Laura М. Sewell, The Software Architect's Profession (Upper Saddle River, NJ: Prentice Hall, 2002), p. 68.
• в совершенстве владеть искусством выслушивания, опрашивания и наблюдения;
• хорошо разбираться в предметной области клиента – будь то банковское обслуживание, деятельность государственных органов, образование, здравоохранение, розничная торговля или скачки;
• получить стратегическое представление о деятельности предприятия клиента, не ограничиваясь тактическим или рабочим обзором его деятельности;
• иметь комплексные познания в технологической области – для того чтобы при разработке архитектурного плана суметь учесть все без исключения варианты стратегических решений;
• наладить конструктивное взаимодействие с клиентом и специалистом, ответственным за конструирование;
• уяснить видение вопроса клиентом и согласованное с ним проектное решение, следить за их неукоснительным соблюдением.
Не кажется ли вам, что выполнение всех
Архитектор должен уметь решать эту проблему, имея в виду два важных понятия: проектные ограничения (design forces), которые обусловливают все решения, принимаемые относительно программных средств, и аналитические позиции (analysis viewpoints), позволяющие принимать решения в соответствии с проектными ограничениями.
Проектные ограничения в архитектурном планировании
Поскольку в формализованном виде дисциплина архитектурного планирования появилась относительно недавно, в ее рамках существует несколько конкурирующих концепций. Мальво (Malveau) и Маубрей (Mowbray) [62] – два эксперта в этой области – приводят список основных концепций. Это каркас Закмана (Zachman), открытая распределенная обработка (Open Distributed Processing, ODP), анализ предметной области, модель 4+1 представлений программной архитектуры и, наконец, академическая программная архитектура. Это уже немало. А знакомы ли вы с положениями каждой из них? Если нет, торопитесь – принимайтесь за изучение перечисленных концепций, поскольку они предоставляют любому специалисту прекрасный инструментарий для создания многократно используемых систем.
62
Raphael С. Malvcau and Thomas Mowbray, Software Architect Bootcamp (Upper Saddle River, NJ: Prentice Hall, 2001).
Разобравшись с положениями различных архитектурных концепций, вы поймете, что все они преследуют общую цель. Она заключается в контроле над проектными ограничениями, которые обуславливают все без исключения программные решения, относящиеся к архитектуре. Проектные ограничения – это те факторы, которые необходимо учитывать с самого начала процесса разработки программного продукта. Они выражают ряд вопросов, на которые любая архитектура должна отвечать. Частично эти вопросы перечислены ниже.
• Сможет ли система предоставить пользователю комфортные условия работы и функционировать согласно его ожиданиям?
• Может ли система функционировать в соответствии с проектным решением, предусматривает ли она модификацию и сопровождение по мере изменения коммерческих потребностей и технологии?
• Минимизирована ли сложность высокоуровневых архитектурных характеристик системы?
• Какой бы продукт ни создавался, в течение нескольких последующих лет его ожидают значительные изменения, причем предпосылки для осуществления этих изменений должны закладываться в фундамент проекта.
• В связи с тем, что ожидается реализация решений в аппаратной части, особое внимание следует уделить созданию, конфигурированию и сопровождению инфраструктуры.
• Достаточна ли компетентность персонала для сопровождения систем, построенных на основе новых технологий? Если в конструировании [63] применяются старые технологии, насколько они перспективны с точки зрения продолжительности использования системы?
Ни в коем случае не забывайте об этих вопросах и проблемах. Обязательно сформулируйте их и донесите до группы разработчиков – ведь умение четко сформулировать вопросы иногда важнее, чем даже знание правильных ответов на них. Может быть, конечно, в этом я преувеличиваю, но, полагаю, мысль вам понятна. Способов наделать глупостей всегда более чем достаточно, и первый вопрос, который вы должны себе задать, звучит так: «Что я должен делать? Какое решение будет правильным?» Задавая адекватные вопросы, вы сможете организовать создание стройной, мощной и долговечной архитектуры.
63
Как просто, оказывается, вернуться к привычной терминологии! Если бы я сказал «…в выращивании применяются старые технологии…», смогли бы вы понять, о чем я говорю?