На первый взгляд ранний выпуск противоречит подходу «пошагового развертывания», но в действительности они весьма хорошо сочетаются. Ранний выпуск отдельных компонентов означает, что каждый компонент может проходить итеративную разработку независимо от других компонентов. Более того, этот подход заставит вас проработать такие проблемные вопросы, как постоянная доступность в ходе развертывания и контроль версий протоколов.
Нечасто встречаются методы, обеспечивающие более высокую коммерческую ценность в сочетании с улучшением архитектурных качеств, но раннее развертывание отдельных компонентов обладает обоими достоинствами.
Биография, автора приведена на стр. 31.
Неоднородность побеждает Эдвард Гарсон
Концепция многоязыкового программирования не нова; характерным примером из прошлого служат системы, в которых клиентская часть написана на Visual Basic и использует серверную часть на базе объектов СОМ, написанных на C++. По сути дела эта архитектура эффективно использовала сильные стороны каждого из упомянутых языков в зените их популярности.
Какие же перемены возродили интерес к многоязыковому программированию?
Новые технические стандарты в сочетании с постоянным ростом ресурсов пропускной способности каналов и вычислительных мощностей сделали возможным реальное использование текстовых протоколов. Те времена, когда эффективные распределенные системы были возможны лишь при использовании хитроумных двоичных протоколов, остались в прошлом. Возможность удаленного взаимодействия на текстовом уровне появилась вместе с веб-службами на базе XML/SOAP и продолжает развиваться в направлении архитектурных стилей REST и других вспомогательных (но не менее важных) протоколов типа Atom и ХМРР.
Благодаря этому новому поколению технологий у нас есть гораздо больше возможностей для гетерогенной разработки, чем когда-либо прежде, просто потому, что полезная информация теперь представляет собой отформатированный текст, который можно генерировать и обрабатывать универсальными средствами. Гетерогенная разработка позволяет для каждой конкретной задачи выбирать наиболее подходящий инструмент, а способность систем взаимодействовать на текстовом уровне
сметает многие прежние преграды.
Теперь архитекторы могут объединять специализированные мощные инструменты, позволяющие вести речь уже не о способности применить подходящий язык, а о способности применить правильную парадигму. Языки программирования поддерживают различные парадигмы, некоторые из которых объектно-ориентированные, а другие функциональные или ориентированные на параллельное программирование. Для конкретных задач или предметных областей одни из этих парадигм подойдут идеально, а другие окажутся несоответствующими. Однако в наши дни эти нетрадиционные (и на первый взгляд разнородные) инструменты объединяются в элегантные гибридные решения гораздо легче, чем прежде.
Эффект этих изменений уже виден в комбинаторном увеличении сложности архитектурной топологии современных программных систем. Этот аспект не столько отражение присущей им разнородности, сколько признак новых возможностей.
Наличие выбора не всегда полезно, но в данном случае оно является «меньшим из зол» в контексте современных программных архитектур. Наша отрасль имеет дело с очень серьезными задачами, поэтому нам необходимы все возможности взаимодействия, которые только можно обеспечить, особенно если задействованные в настоящий момент платформы не очень хорошо подходят для решения этих задач.
В наши дни работа архитектора стала еще более сложной из-за того, что границы технологий трещат под напором новых возможностей. Примите этот вызов, учитесь мыслить широко и обратите богатство возможностей в свою пользу: неоднородность побеждает.
Эдвард Гарсон (Edward Garson) стал страстным энтузиастом программирования еще с тех времен, когда учился программировать на Logo на компьютере Apple II. В настоящее время он работает архитектором программного обеспечения в Центре гибких методологий программирования в Zuhlke Engineering одной из ведущих швейцарских технологических компаний.
Не забывайте о производительности Крейг Рассел
Многие архитекторы ставят производительность на последнее место в своих списках возможно, потому, что компьютеры обрабатывают данные несопоставимо быстрее своих пользователей, и архитектору кажется, что скорость системы окажется приемлемой. А если современным системам не хватит быстродействия, обо всем позаботится закон Мура. Однако скорость работы оборудования лишь один из аспектов системы.
Производительность иногда рассматривается просто как промежуток времени, который нужен системе, чтобы отреагировать на введенные пользователем данные. Но архитекторы систем должны учитывать разнообразные аспекты производительности, включая производительность труда аналитиков и программистов, реализующих дизайн, производительность общения пользователя с системой, а также быстродействие неинтерактивных компонентов.
Производительность труда людей, строящих систему, часто называется