Например, вам может пригодиться прошлый опыт. Если вы прежде уже занимались реализацией систем, то у вас имеется некоторое представление о планировании аппаратной мощности — хотя бы на основании ретроспективного анализа. Вы можете также обсудить эту тему со своим клиентом и убедить его выделить средства на планирование мощности оборудования. Финансирование такой деятельности часто оказывается намного выгоднее покупки оборудования сверх реально необходимого. В этом случае ключевая роль отводится горизонтальной масштабируемости: [36] оборудование добавляется по мере надобности вместо избыточных закупок в самом начале. Чтобы «горизонтальная стратегия» работала, архитектор ПО должен постоянно проводить измерения вычислительной мощности и изолировать программные компоненты для запуска в среде с прогнозируемыми показателями производительности.

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

Камал Викраманаяке (Kamal Wickramanayake) — архитектор аппаратного и программного обеспечения, живет на Шри-Ланке. Является обладателем сертификата TOGAF от The Open Group.

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

Допустим, кто-то сказал вам, что модульные тесты не приносят непосредственной пользы, и вы даете своим разработчикам указание не углубляться в их создание. Впоследствии это значительно затруднит модификацию готовой системы и породит чувство неуверенности во внесенных изменениях. Относительно небольшие изменения потребуют гораздо большего объема ручного тестирования, что приведет к нестабильности и росту затрат на сопровождение, а получившийся дизайн нельзя будет назвать полностью тестируемым (не говоря уже о соответствии принципу «опережающего тестирования»). [37]

Серьезной архитектурной ошибкой является и попытка приспособить существующую систему к тем целям, для которых она не предназначалась, под тем предлогом, что использование существующей системы может каким-то образом снизить затраты. Например, архитектурные компоненты BPEL [38] в сочетании с триггерами баз данных можно приспособить для реализации системы на основе асинхронной передачи сообщений. Такие решения обычно возникают из соображений удобства либо потому, что эта архитектура известна вам или клиенту. Однако действительным основанием для такого выбора могут послужить только четко сформулированные требования — это обязательное условие. Неудачные решения на ранней стадии проекта обходятся очень дорого, когда архитектуру системы приходится изменять в соответствии с новыми требованиями.

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

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

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

Скот Макфи (Scot Mcphee) — австралийский разработчик и архитектор с 15-летним опытом программирования и проектирования приложений. Последние 8 лет работал главным образом с технологиями семейства J2EE.

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

Мой совет: не поддавайтесь искушению довести дизайн или реализацию системы до совершенства! Ориентируйтесь на отметку «достаточно хорошо» и остановитесь, когда вы доберетесь до нее.

«Что именно означает „достаточно хорошо“?» — спросите вы. Это означает, что оставшиеся недочеты не оказывают сколько-нибудь заметного влияния на функциональность, удобство сопровождения или производительность системы. Архитектура и дизайн идут рука об руку. Реализованная система работает и соответствует требованиям к производительности. Программный код понятен, лаконичен и хорошо документирован. Можно ли сделать лучше? Конечно, но и так достаточно хорошо — поэтому остановитесь. Заявите о своей победе и переходите к следующей задаче.