Ясность характеризует процесс общения. Никто в вашей группе не станет читать 100-страничный документ с обоснованием ваших архитектурных решений. Умение четко и ясно выражать свои мысли жизненно важно для успеха любого программного проекта. С самого начала работы над проектом придерживайтесь простых объяснений и ни в коем случае не начинайте составлять длинные описания в Word. Используйте такие инструменты, как Visio, для создания простых диаграмм, поясняющих ваши идеи. Диаграммы должны быть простыми, потому что они почти наверняка будут часто изменяться. Еще одним эффективным средством распространения информации являются неформальные встречи. Лучший способ донести вашу мысль до участников проекта — собрать группу разработчиков (или других архитекторов) в одной комнате и изобразить свои идеи на доске. Обязательно захватите с собой цифровой фотоаппарат (ничто так не раздражает, как требование освободить конференц-зал, когда вы только что закончили рисовать). После собрания сделайте снимок, размножьте его и распространите среди остальных участников через вики. Отложите создание пространных документов и направьте усилия на то, чтобы донести свои идеи до коллег, а уже потом можно будет подумать и о более подробном изложении ваших архитектурных решений.

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

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

Если «общение — король», то ясность и лидерство — его верные слуги.

Марк Ричардс (Mark Richards) — директор и ведущий архитектор в фирме Collaborative Consulting, LLC, где он занимается разработкой архитектуры и проектированием крупномасштабных сервис-ориентированных решений на базе J2EE и других технологий главным образом в области финансовых операций. Работает в программной отрасли с 1984 года, обладает значительным опытом проектирования и разработки на J2EE, объектно-ориентированного проектирования и разработки, а также опытом системной интеграции.

Производительность приложения определяется его архитектурой. На первый взгляд кажется, что это утверждение должно быть очевидным, но опыт реальной работы показывает обратное. Например, архитекторы программного обеспечения нередко полагают, что проблемы с производительностью приложения можно решить простым переходом на программную инфраструктуру от другого производителя. Источником этой веры может быть рекламная шумиха вокруг результатов тестирования — например, заявляется, что продукт фирмы-лидера на 25 % превосходит по производительности ближайшего конкурента. Однако если продукт-лидер выполняет операцию за 3 миллисекунды, а конкурирующий продукт — за 4 миллисекунды, заявленные 25 % (одна миллисекунда) значат очень мало на фоне общей низкой производительности, уходящей корнями в неэффективность архитектуры.

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

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

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

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