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

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

«Срезание углов» сейчас обойдется слишком дорого потом

Скот Макфи

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

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

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

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

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

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

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

Лучшее — враг хорошего

Грег Найберг

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

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

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

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

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

Помните, что разработка приложений — не конкурс красоты. Перестаньте выискивать недочеты и тратить время на поиски совершенства.

Грег Найберг (Greg Nyberg) — независимый консультант в области J2EE с 18-летним опытом проектирования, построения, тестирования и развертывания крупномасштабных транзакционных приложений, таких как системы оформления предварительных заказов, центры приема звонков и потребительские веб-сайты. Является, автором справочника «WebLogic 6.1 Server Workbook for Enterprise JavaBeans, 3-е издание» (O’Reilly) и ведущим автором книги «Mastering WebLogic Server» (Wiley).

Остерегайтесь «хороших идей»

Грег Найберг

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

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

Тут у кого-то появляется «хорошая идея», вы с ней соглашаетесь — и вот вы уже переделываете проект под свежую версию Hibernate, чтобы воспользоваться ее новейшими возможностями, или используете AJAX на некоторых веб-страницах, потому что разработчик показал пользователям, как круто это смотрится, или пересматриваете архитектуру базы данных, чтобы задействовать те возможности по работе с XML, которые предлагает СУБД. Вы говорите руководителю проекта, что для реализации этой «хорошей идеи» понадобится еще несколько недель, однако изменения затрагивают больший объем кода, чем предполагалось, и график начинает трещать по швам. Вдобавок, приняв первую «хорошую идею», вы, как в поговорке, «выпустили джинна из бутылки»: вскоре на