97 этюдов для архитекторов программных систем

Новые технические стандарты в сочетании с постоянным ростом ресурсов — пропускной способности каналов и вычислительных мощностей — сделали возможным реальное использование текстовых протоколов. Те времена, когда эффективные распределенные системы были возможны лишь при использовании хитроумных двоичных протоколов, остались в прошлом. Возможность удаленного взаимодействия на текстовом уровне появилась вместе с веб-службами на базе XML/SOAP и продолжает развиваться в направлении архитектурных стилей REST и других вспомогательных (но не менее важных) протоколов типа Atom и ХМРР.

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

Теперь архитекторы могут объединять специализированные мощные инструменты, позволяющие вести речь уже не о способности применить подходящий язык, а о способности применить правильную парадигму. Языки программирования поддерживают различные парадигмы, некоторые из которых объектно-ориентированные, а другие функциональные или ориентированные на параллельное программирование. Для конкретных задач или предметных областей одни из этих парадигм подойдут идеально, а другие окажутся несоответствующими. Однако в наши дни эти нетрадиционные (и на первый взгляд разнородные) инструменты объединяются в элегантные гибридные решения гораздо легче, чем прежде.

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

Наличие выбора не всегда полезно, но в данном случае оно является «меньшим из зол» в контексте современных программных архитектур. Наша отрасль имеет дело с очень серьезными задачами,[20] поэтому нам необходимы все возможности взаимодействия, которые только можно обеспечить, особенно если задействованные в настоящий момент платформы не очень хорошо подходят для решения этих задач.[21]

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

Эдвард Гарсон (Edward Garson) стал страстным энтузиастом программирования еще с тех времен, когда учился программировать на Logo на компьютере Apple II. В настоящее время он работает архитектором программного обеспечения в Центре гибких методологий программирования в Zuhlke Engineering — одной из ведущих швейцарских технологических компаний.

Не забывайте о производительности Крейг Рассел

Представьте себе автомобиль — просторный, удобный, экономичный, недорогой и утилизируемый на 98 %. Хотите такой? Конечно. Кто угодно захочет. Ах, да, единственная проблема: его максимальная скорость составляет 10 км/ч. Не передумали? Этот маленький пример наглядно показывает, что производительность так же важна, как и любой другой критерий.

Многие архитекторы ставят производительность на последнее место в своих списках — возможно, потому, что компьютеры обрабатывают данные несопоставимо быстрее своих пользователей, и архитектору кажется, что скорость системы окажется приемлемой. А если современным системам не хватит быстродействия, обо всем позаботится закон Мура. Однако скорость работы оборудования — лишь один из аспектов системы.

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

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