Грегор Хоп (Gregor Hohpe) — архитектор ПО в компании Google, Inc. Грегор является общепризнанным экспертом в области асинхронных архитектур для систем обмена сообщениями и сервис-ориентированных архитектур. Он является соавтором книги «Enterprise Integration Patterns»[30] (Addison-Wesley Professional), регулярно выступает на технических конференциях по всему миру.

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

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

Архитектор, помешанный на тотальном контроле, — фигура из прошлого; решения, которые он создает, являются сильно связанными и хрупкими. С другой стороны, полная и неограниченная свобода приложения — верный путь к хаосу. Ослабление контроля необходимо дополнить другими механизмами, чтобы «полет по приборам» не происходил без самих приборов. Но какие приборы есть в нашем распоряжении? Вообще-то их более чем достаточно. Современные языки программирования поддерживают рефлексию (reflection), и почти все платформы предоставляют динамические метрики времени выполнения. По мере того как система становится более настраиваемой, ее текущая конфигурация сама становится отличным источником информации. Так как разобраться в слишком большом объеме низкоуровневых данных довольно трудно, создайте на их основе модель. Например, когда станет ясно, какие компоненты отправляют сообщения по тем или иным логическим каналам и какие компоненты ожидают поступления сообщений по этим каналам, вы сможете построить граф передачи данных между компонентами. Эту процедуру можно производить каждые несколько минут или часов, создавая точную и оперативную картину системы в ходе ее развития. Считайте это своего рода «MDA наоборот»:[31] вместо модели, управляющей архитектурой, вы строите гибкую архитектуру и формируете модель на основании текущего состояния системы.

Во многих случаях модель можно легко визуализировать, построив действительно «общую картину». Однако боритесь с соблазном заполнить квадратиками и линиями полотно 3x5 метров в стремлении изобразить все классы вашей системы. Такая картина сойдет за произведение современного искусства, но ее не назовешь полезной программной моделью. Вместо этого лучше использовать «вид с высоты 300 метров», как рекомендует Эрик Дорненбург, — тот уровень абстракции, который содержит действительно полезную информацию. Вдобавок вы сможете проследить за тем, чтобы в модели не было нарушений простейших правил корректности — циклических ссылок в графе зависимостей или отправки сообщений по непрослушиваемым логическим каналам.

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

Биография автора приведена ранее.

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

Способность Януса смотреть вперед и назад, видеть прошлое и будущее является исключительно ценным навыком как для архитектора программного обеспечения, так и для архитектора-строителя. Архитектор стремится объединить реальность со своим представлением о ней, прошлые достижения — с планами на будущее, ожидания руководства — с ограничениями разработки. Наведение таких мостов — важнейшая часть работы архитектора. Часто у архитектора возникает чувство, что в своем стремлении довести проект до завершения ему приходится преодолевать пропасти, которые созданы воздействием сил, направленных в противоположные стороны. Это могут быть, например, простота в использовании и безопасность или соответствие текущим бизнес-процессам и ориентация на перспективу, обрисованную руководством. У хорошего архитектора должно быть «две головы», способные удерживать две разные идеи или концепции, две разные цели или точки зрения, чтобы он мог создать продукт, удовлетворяющий все заинтересованные стороны проекта.

Обратите внимание: у Януса две головы, а не просто два лица. Иначе говоря, он обладает дополнительной парой ушей и глаз, что повышает его осведомленность и восприимчивость. Хороший IT-архитектор должен быть превосходным слушателем и аналитиком. Понимание причин, по которым осуществляются инвестиции, жизненно важно для определения целей и представлений руководства о будущем организации. Умение оценивать технические навыки вашего персонала в области проектирования и используемых в проекте технологий поможет сформировать подходящие пары для обучения и работы. Знание о том, какие решения с открытым кодом можно использовать в сочетании с теми или иными коробочными коммерческими программами, заметно сократит бюджет и сроки реализации проекта. Хороший архитектор должен разбираться в этих и многих других составляющих процесса разработки и уметь ставить их себе на службу, чтобы обеспечить успех проекта в целом.

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