Лучший способ обучаться — наблюдать за другими; именно так мы учимся в детстве. Хороший архитектор должен уметь выявить проблему, собрать команду и, не занимаясь поисками виновных, объяснить суть проблемы, а затем предложить элегантное решение или обходной путь. При этом архитектор может попросить у команды помощи, нисколько не теряя авторитета. Разработчики должны ощущать свой вклад в решение задачи, но архитектор при этом направляет ход обсуждения и определяет правильный подход. Архитекторам следует присоединяться к команде уже на самых ранних стадиях проекта; они должны не сидеть в башне из слоновой кости, указывая оттуда путь вперед, а работать «в поле» вместе со всеми остальными. Вопросы выбора стратегического направления или технологии не следует превращать в самостоятельные исследования или новые проекты — к ним надо подходить прагматически, разыскивая ответ в ходе практической работы или обращаясь за советом к коллегам-архитекторам (все хорошие архитекторы знают друг друга).

Хороший архитектор обязан на уровне эксперта владеть как минимум одним из инструментов своей профессии, например интегрированной средой разработки (IDE); помните, что архитектор должен быть практиком. Вполне логично, что архитектору ПО следует хорошо знать IDE, архитектору баз данных — инструментарий построения диаграмм «сущность-связь» (ER-диаграмм), а информационному архитектору — инструменты XML-моделирования. Однако ведущий архитектор обязан уметь применять инструменты всех уровней, от контроля сетевого трафика с использованием Wireshark до моделирования сложных финансовых сообщений в XMLSpy, — для него не существует слишком низких или слишком высоких уровней.

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

Джон Дэвис (John Davies) в настоящее время является ведущим архитектором в фирме Revolution Money (США). Недавно основал новую компанию Incept5.

Сборка давно перестала играть роль «Большого взрыва» в разработке проектов. И архитекторы (как уровня приложения, так и корпоративного уровня) должны поощрять использование методов и инструментов непрерывной интеграции в каждом проекте.

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

Непрерывная интеграция воздействует на неотъемлемый элемент процесса разработки ПО — точку преобразования исходного кода в работающее приложение. В этой точке происходит объединение и тестирование составных частей проекта. Вам, вероятно, доводилось слышать принцип «Выполняйте сборку рано и часто» («Build early and often»); когда-то этот принцип служил методом снижения рисков, избавляя от неприятных сюрпризов в процессе разработки. В наши дни на смену «ранней и частой сборке» пришла непрерывная интеграция, которая также включает в себя сборку, но добавляет к ней возможности, улучшающие взаимодействие в команде разработчиков и повышающие ее координацию.

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

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

Дэйв Бартлетт (Dave Bartlett) — увлеченный своим делом профессионал. За 25 с лишним лет он успел побывать программистом, разработчиком, архитектором, руководителем, консультантом и преподавателем. В настоящее время он выполняет работы для клиентов Commotion Technologies, Inc. (частная консалтинговая компания), а также читает лекции в Высшей технической школе Пенсильванского университета. Его основные текущие проекты связаны с Федеральным резервным банком в Филадельфии, которому он помогает проектировать и создавать веб-приложения, порталы и комплексные приложения для взаимодействия с Федеральной резервной системой и Казначейством США.

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