Дэйв Мурхед (Dave Muirhead) — ветеран в области искусства программирования и бизнес-технологий, владелец и ведущий консультант Blue River Systems Group, LLC (BRSG) — расположенной в Денвере компании, оказывающей консультационные услуги в сфере бережливой разработки программного обеспечения и технических стратегий.

Типичная проблема многих компонентных инфраструктур (framework), библиотек классов, базовых сервисов и прочего инфраструктурного кода заключается в том, что они проектируются с расчетом на универсальное применение, без привязки к конкретным приложениям. В результате мы получаем ошеломляющий набор возможностей и настроек, которые часто не используются вообще или используются не по назначению, а то и попросту оказываются бесполезными. Большинство разработчиков работает над конкретными системами, и стремление к неограниченной универсальности редко способно сослужить им хорошую службу. Лучший путь к универсальности пролегает через глубокое понимание известных конкретных примеров и анализ их сути с целью поиска фундаментального общего решения: простота как результат практического опыта, а не универсальность, опирающаяся на умозрительные догадки.

Приоритет простоты перед универсальностью помогает сделать выбор между двумя архитектурными альтернативами, равнозначными в остальных отношениях. Когда возможны два решения, отдавайте предпочтение более простому и ориентированному на конкретную потребность, а не более изощренному и претендующему на универсальность. Конечно, вполне может случиться (и не так уж редко случается), что более простое решение на практике окажется и более универсальным. Но, даже если этого не произойдет, легче изменить простое решение, когда вы хорошо представляете, что же вам требуется, нежели нужным образом адаптировать «универсальное» решение, которое, как назло, оказалось недостаточно универсальным.

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

Обобщение иногда позволяет привести задачу к более фундаментальному виду; в созданном решении воплощаются закономерности нескольких известных примеров — четкие, компактные и хорошо обоснованные. Однако чрезмерное обобщение само превращается в задачу, которая ведет в противоположном направлении и повышает сложность, вместо того чтобы сокращать ее. Стремление к абстрактным обобщениям часто порождает решения, не привязанные к реалиям фактической разработки. Такие обобщения опираются на предположения, которые позднее оказываются неверными, предлагают варианты выбора, которые позже оказываются невостребованными, и создают балласт, который потом трудно или невозможно удалить. В конечном итоге это лишь повышает второстепенную сложность, с которой придется столкнуться будущим разработчикам и архитекторам.

Многие архитекторы высоко ценят универсальность, но такое отношение не должно быть безусловным. Как правило, люди не готовы платить за универсальность (или не нуждаются в ней): перед ними обычно стоит совершенно конкретная задача, и они ценят конкретное решение этой задачи. Универсальность и гибкость могут проявиться при создании конкретных решений, но если при этом мы слишком быстро снимемся с якоря и забудем о конкретике, то начнем дрейфовать в море безграничных возможностей — море, полном хитроумных настроек, громоздких (не просто обширных) списков параметров, бескрайних интерфейсов и неправомерных абстракций. В стремлении к абстрактной гибкости часто (случайно или намеренно) утрачиваются ценные свойства альтернативных, более простых решений.

Кевлин Хенни (Kevlin Неппеу) — независимый консультант и преподаватель. Он специализируется на шаблонах и архитектуре, методах и языках программирования, процессах и практике разработки. Является соавтором книг «А Pattern Language for Distributed Computing» (Язык шаблонов для распределенных компьютерных систем) и «On Patterns and Pattern Languages» (О шаблонах и языках шаблонов) — обе книги опубликованы издательством Wiley.

Хороший архитектор должен подавать личный пример другим. Он должен быть способен заменить любого члена своей команды и выполнить любую работу — от прокладки сети и настройки процесса сборки до написания модульных тестов и выполнения тестов производительности. Без хорошего понимания всего диапазона технологий архитектор мало чем отличается от обычного руководителя проекта. Члены команды могут обладать более глубокими знаниями в своих узких областях — это совершенно нормально, — но вряд ли они смогут доверять своему архитектору, если тот не разбирается в используемых технологиях. Как уже было сказано, архитектор — это интерфейс между технической командой и бизнесом, а значит, он должен понимать все технические аспекты, чтобы играть роль представителя команды перед бизнес-руководством, не обращаясь постоянно за помощью. Из тех же соображений архитектор должен понимать деловые аспекты организации, чтобы успешно привести разработчиков к цели — удовлетворению коммерческих интересов компании.

Работа архитектора сродни работе пилота самолета: он может не выглядеть занятым, но в действительности использует десятилетия накопленного опыта для постоянного наблюдения за ситуацией и немедленно вмешивается при возникновении нештатной ситуации. Руководитель проекта (второй пилот) обеспечивает повседневное управление, избавляя архитектора от рутины и управления персоналом. В конечном итоге архитектор должен отвечать за качество продукта и его своевременную сдачу. Эти задачи трудно решить без личного авторитета, который играет чрезвычайно важную роль в успехе любого проекта.

Лучший способ обучаться — наблюдать за другими; именно так мы учимся в детстве. Хороший архитектор должен уметь выявить проблему, собрать команду и, не занимаясь поисками виновных, объяснить суть проблемы, а затем предложить элегантное решение или обходной путь. При этом архитектор может попросить у команды помощи, нисколько не теряя авторитета. Разработчики должны ощущать свой вклад в решение задачи, но архитектор при этом направляет ход обсуждения и определяет правильный подход. Архитекторам следует присоединяться к команде уже на самых ранних стадиях проекта; они должны не сидеть в башне из слоновой кости, указывая оттуда путь вперед, а работать «в поле» вместе со всеми остальными. Вопросы выбора стратегического направления или технологии не следует превращать в самостоятельные исследования или новые проекты — к ним надо подходить прагматически, разыскивая ответ в ходе практической работы или обращаясь за советом к коллегам-архитекторам (все хорошие архитекторы знают друг друга).

Хороший архитектор обязан на уровне эксперта владеть как минимум одним из инструментов своей профессии, например интегрированной средой разработки (IDE); помните, что архитектор должен быть практиком. Вполне логично, что архитектору ПО следует хорошо знать IDE, архитектору баз данных — инструментарий построения диаграмм «сущность-связь» (ER-диаграмм), а информационному архитектору — инструменты XML-моделирования. Однако ведущий архитектор обязан уметь применять инструменты всех уровней, от контроля сетевого трафика с использованием Wireshark до моделирования сложных финансовых сообщений в XMLSpy, — для него не существует слишком низких или слишком высоких уровней.

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