97 этюдов для архитекторов программных систем
Шрифт:
Дивный новый мир компьютерных технологий трещит по швам — так что же нам делать? Как это часто бывает, осознание проблемы становится первым важным шагом к ее решению.
Распрощайтесь со старой доброй детерминированной архитектурой стека вызовов, в которой вы сами определяли, что, когда и в каком порядке происходит. Вместо этого будьте готовы реагировать на события в любое время и в любом порядке, восстанавливая состояние системы по мере необходимости. Выдавайте асинхронные запросы параллельно вместо последовательного вызова методов. Чтобы избежать полного хаоса, моделируйте свое приложение, используя управляемые событиями цепочки процессов или модели состояний. Нейтрализуйте ошибки посредством коррекции, повторных попыток или тестовых операций.
Звучит слишком устрашающе? Вы на такое не рассчитывали? К счастью, в реальном мире с похожими проблемами
29
См. http://www.eaipatterns.com/ramblings/18_starbucks.html.
Грегор Хоп (Gregor Hohpe) — архитектор ПО в компании Google, Inc. Грегор является общепризнанным экспертом в области асинхронных архитектур для систем обмена сообщениями и сервис-ориентированных архитектур. Он является соавтором книги «Enterprise Integration Patterns» [30] (Addison-Wesley Professional), регулярно выступает на технических конференциях по всему миру.
Не контролируйте — наблюдайте
Грегор Хоп
30
Хоп Г., Вульф Б. «Шаблоны интеграции корпоративных приложений». — М.: Вильямс, 2007.
Современные системы являются распределенными и слабо связанными (loosely coupled). Построение слабо связанных систем создает немало хлопот, так почему же мы идем на это? Потому что хотим, чтобы наши системы были гибкими и не разваливались при малейших изменениях. Это критическое свойство в современных средах, где мы контролируем лишь небольшую часть своего приложения, а все остальное существует в виде распределенных служб или пакетов, находящихся под контролем других отделов или внешних производителей.
Итак, стремление создать систему гибкую и способную развиваться со временем — дело хорошее. Но это означает также, что наша система будет постепенно изменяться. Другими словами, «сегодня система уже не та, какой была вчера». К сожалению, это заметно усложняет документирование системы. Все знают, что документация устаревает в момент печати, но в постоянно изменяющейся системе дела могут обстоять еще хуже. Более того, построение гибкой системы обычно усложняет архитектуру, и получить пресловутую «общую картину» становится еще труднее. Например, если все компоненты системы обмениваются информацией по логическим, настраиваемым каналам, то, чтобы получить представление о происходящем, необходимо взглянуть на конфигурацию каналов. Отправка сообщений в логическое пойди-туда-не-знаю-куда вряд ли приведет к ошибке компиляции, но наверняка огорчит пользователя, действие которого было запаковано в это сообщение.
Архитектор, помешанный на тотальном контроле, — фигура из прошлого; решения, которые он создает, являются сильно связанными и хрупкими. С другой стороны, полная и неограниченная свобода приложения — верный путь к хаосу. Ослабление контроля необходимо дополнить другими механизмами, чтобы «полет по приборам» не происходил без самих приборов. Но какие приборы есть в нашем распоряжении? Вообще-то их более чем достаточно. Современные языки программирования поддерживают рефлексию (reflection), и почти все платформы предоставляют динамические метрики времени выполнения. По мере того как система становится более настраиваемой, ее текущая конфигурация сама становится отличным источником информации. Так как разобраться в слишком большом объеме низкоуровневых данных довольно трудно, создайте
31
MDA (Model-Driven Architecture) — архитектура, управляемая моделями.
Во многих случаях модель можно легко визуализировать, построив действительно «общую картину». Однако боритесь с соблазном заполнить квадратиками и линиями полотно 3x5 метров в стремлении изобразить все классы вашей системы. Такая картина сойдет за произведение современного искусства, но ее не назовешь полезной программной моделью. Вместо этого лучше использовать «вид с высоты 300 метров», как рекомендует Эрик Дорненбург, — тот уровень абстракции, который содержит действительно полезную информацию. Вдобавок вы сможете проследить за тем, чтобы в модели не было нарушений простейших правил корректности — циклических ссылок в графе зависимостей или отправки сообщений по непрослушиваемым логическим каналам.
Ослабление контроля пугает, особенно когда речь идет об архитектуре системы. Но в сочетании с тщательным наблюдением, построением моделей и проверкой корректности оно, вероятно, является единственным разумным подходом к построению архитектуры программного обеспечения в XXI веке.
Биография автора приведена ранее.
Архитектор Янус
Дэвид Бартлетт
У древних римлян Янус считался богом начала и завершения, дверей и проходов. Обычно его изображали с двумя головами, направленными в разные стороны; этот символ часто встречается на монетах и в кино. Янус символизирует переходы и изменения в жизни — рождение, вступление в брак, достижение зрелости — от прошлого к будущему, от юности к старости.
Способность Януса смотреть вперед и назад, видеть прошлое и будущее является исключительно ценным навыком как для архитектора программного обеспечения, так и для архитектора-строителя. Архитектор стремится объединить реальность со своим представлением о ней, прошлые достижения — с планами на будущее, ожидания руководства — с ограничениями разработки. Наведение таких мостов — важнейшая часть работы архитектора. Часто у архитектора возникает чувство, что в своем стремлении довести проект до завершения ему приходится преодолевать пропасти, которые созданы воздействием сил, направленных в противоположные стороны. Это могут быть, например, простота в использовании и безопасность или соответствие текущим бизнес-процессам и ориентация на перспективу, обрисованную руководством. У хорошего архитектора должно быть «две головы», способные удерживать две разные идеи или концепции, две разные цели или точки зрения, чтобы он мог создать продукт, удовлетворяющий все заинтересованные стороны проекта.
Обратите внимание: у Януса две головы, а не просто два лица. Иначе говоря, он обладает дополнительной парой ушей и глаз, что повышает его осведомленность и восприимчивость. Хороший IT-архитектор должен быть превосходным слушателем и аналитиком. Понимание причин, по которым осуществляются инвестиции, жизненно важно для определения целей и представлений руководства о будущем организации. Умение оценивать технические навыки вашего персонала в области проектирования и используемых в проекте технологий поможет сформировать подходящие пары для обучения и работы. Знание о том, какие решения с открытым кодом можно использовать в сочетании с теми или иными коробочными коммерческими программами, заметно сократит бюджет и сроки реализации проекта. Хороший архитектор должен разбираться в этих и многих других составляющих процесса разработки и уметь ставить их себе на службу, чтобы обеспечить успех проекта в целом.