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

Слишком часто архитекторы программного обеспечения обитают в башнях из слоновой кости, спуская оттуда разработчикам спецификации и навязывая им технологии и направления. Сплошь и рядом это приводит к раздорам, за которыми быстро следует «народное восстание». В итоге появляется программный продукт, который не имеет ничего общего с исходными требованиями. Каждый архитектор программного обеспечения должен уметь объяснять своим коллегам цели и задачи программного проекта. Ключами к эффективному общению являются ясность и лидерство.

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

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

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

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

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

Производительность приложения определяется его архитектурой Рэнди Стаффорд

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