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

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

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

Рэнди Стаффорд (Randy Stafford) — профессионал, в области создания программного обеспечения, обладающий 20-летним опытом работы в качестве разработчика, аналитика, архитектора, менеджера, консультанта и автора/лектора. В настоящее время занимается разработкой промежуточного (middleware) программного обеспечения в составе группы А-Team фирмы Oracle, а также участвует в концептуальных проектах, занимается оценкой архитектуры и помогает устранять кризисы производства различным организациям во всем мире. Основные области его специализации — сервис-ориентированные архитектуры, производительность, высокая доступность и JEE/ORM.

Ищите истинный смысл требований Эйнар Ландре

Заказчики и конечные пользователи часто под видом требования выдвигают то, что им кажется эффективным решением некоторой задачи. Классический пример такого рода приводит Гарри Хиллейкер (Harry Hillaker), ведущий конструктор истребителя F-16 Falcon. Перед его группой была поставлена цель спроектировать самолет, развивающий скорость М2-2,5, что было (и вероятно, остается) весьма нетривиальной задачей, особенно если сопутствующая цель состоит в создании «дешевого» легкого самолета. Учтите, что сила, необходимая для преодоления сопротивления воздуха, при удвоении скорости полета возрастает вчетверо, и представьте себе, как это обстоятельство влияет на вес самолета.

Когда конструкторская группа спросила заказчиков из ВВС, зачем им нужна скорость М2-2,5, те ответили: «Чтобы самолет мог при необходимости выйти из боя». Когда настоящая потребность стала очевидной, конструкторы смогли решить главную проблему и представить работоспособное решение: подвижный самолет с высокой тяговооруженностью, обеспечивающей хорошее ускорение и маневренность вместо высокой максимальной скорости.

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