Как пасти котов. Наставление для программистов, руководящих другими программистами

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

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

Создание архитектуры – это активный творческий процесс, который отнюдь не ограничивается сидением за клавиатурой, фиксацией коммерческих требований и реализацией компонентов, которые способны эти требования удовлетворить, в коде. В процессе работы над архитектурой вам придется абстрагироваться от своих механистических обязанностей и максимально углубиться в задачу, которую предстоит решить. Спору нет – во многих случаях решение оказывается вполне механистическим, то есть чисто программным. И тем не менее, если вы не разберетесь в задачах, стоящих перед своей компанией, обеспечить продуктам длительное и продуктивное существование вам, скорее всего, не удастся. Марк и Лора Сьюелл (Marc & Laura Sewell) в своей работе о роли архитекторов перечисляют ряд важнейших действий, которые должны предшествовать составлению любого проектного плана[61]. С точки зрения этих авторов, любой архитектор должен:

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

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

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

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

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

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

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

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

Проектные ограничения в архитектурном планировании