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

Поскольку в формализованном виде дисциплина архитектурного планирования появилась относительно недавно, в ее рамках существует несколько конкурирующих концепций. Мальво (Malveau) и Маубрей (Mowbray) [62] Raphael С. Malvcau and Thomas Mowbray, Software Architect Bootcamp (Upper Saddle River, NJ: Prentice Hall, 2001). – два эксперта в этой области – приводят список основных концепций. Это каркас Закмана (Zachman), открытая распределенная обработка (Open Distributed Processing, ODP), анализ предметной области, модель 4+1 представлений программной архитектуры и, наконец, академическая программная архитектура. Это уже немало. А знакомы ли вы с положениями каждой из них? Если нет, торопитесь – принимайтесь за изучение перечисленных концепций, поскольку они предоставляют любому специалисту прекрасный инструментарий для создания многократно используемых систем.

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

• Сможет ли система предоставить пользователю комфортные условия работы и функционировать согласно его ожиданиям?

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

• Минимизирована ли сложность высокоуровневых архитектурных характеристик системы?

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

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

• Достаточна ли компетентность персонала для сопровождения систем, построенных на основе новых технологий? Если в конструировании [63] Как просто, оказывается, вернуться к привычной терминологии! Если бы я сказал «…в выращивании применяются старые технологии…», смогли бы вы понять, о чем я говорю? применяются старые технологии, насколько они перспективны с точки зрения продолжительности использования системы?

Ни в коем случае не забывайте об этих вопросах и проблемах. Обязательно сформулируйте их и донесите до группы разработчиков – ведь умение четко сформулировать вопросы иногда важнее, чем даже знание правильных ответов на них. Может быть, конечно, в этом я преувеличиваю, но, полагаю, мысль вам понятна. Способов наделать глупостей всегда более чем достаточно, и первый вопрос, который вы должны себе задать, звучит так: «Что я должен делать? Какое решение будет правильным?» Задавая адекватные вопросы, вы сможете организовать создание стройной, мощной и долговечной архитектуры.

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

• Как будет проходить взаимодействие пользователей с системой? (Эту аналитическую позицию часто называют вариантной.)

• Какие компоненты требуется собрать для того, чтобы обеспечить функционирование системы?

• Каков механизм взаимодействия компонентов, благодаря которому система функционирует?

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

• Как предполагается поставить систему клиенту?

Задаетесь ли вы этими вопросами о предполагаемом продукте в ходе проектных совещаний (о них мы говорили в предыдущей главе)? Без них не обойтись – в противном случае у вас получится случайная архитектура, а это крайне опасный негативный эталон. Не забывайте, что переработать архитектуру значительно сложнее и потенциально разрушительнее, чем реконструировать компоненты. Этот фактор риска в процессе проектирования следует постоянно иметь в виду.

Переработать архитектуру значительно сложнее и потенциально разрушительнее, чем реконструировать компоненты.

Держу пари, что вы сомневаетесь: нужно ли вам все это знать? Полагаю, что если вы действительно хотите стать эффективным техническим лидером, это знание необходимо. Если вы пользуетесь языком программирования четвертого поколения (4GL, например, Visual Basic), а не, скажем, С++, то больше внимания следует уделять разработке архитектуры системы. Даже при условии применения С++ создать плохую архитектуру не представляет труда – что уж говорить о языках четвертого поколения! Да, действительно, они позволяют оперативно выстроить механизм взаимодействия пользователя с системой, но это, как вы понимаете, лишь ее оболочка. Термин быстрая разработка приложений (Rapid Application Development, RAD), возникнув на заре создания программных продуктов под Windows, первоначально отражал высокие темпы выхода продуктов на рынок, достигавшиеся средствами языков четвертого поколения. В сегодняшних условиях «быстрая» разработка в большинстве случаев приводит к появлению некачественных программных продуктов. Мне даже кажется, что аббревиатуру RAD сегодня более уместно расшифровывать как «разработка мерзких приложений» (Rotten Application Development). Первоочередное внимание следует уделять, говоря анатомическим языком, скелету, нервной системе и внутренним органам. В противном случае вы рискуете извергнуть очередную халтуру.

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