Например, вам может пригодиться прошлый опыт. Если вы прежде уже занимались реализацией систем, то у вас имеется некоторое представление о планировании аппаратной мощности хотя бы на основании ретроспективного анализа. Вы можете также обсудить эту тему со своим клиентом и убедить его выделить средства на планирование мощности оборудования. Финансирование такой деятельности часто оказывается намного выгоднее покупки оборудования сверх реально необходимого. В этом случае ключевая
роль отводится горизонтальной масштабируемости: оборудование добавляется по мере надобности вместо избыточных закупок в самом начале. Чтобы «горизонтальная стратегия» работала, архитектор ПО должен постоянно проводить измерения вычислительной мощности и изолировать программные компоненты для запуска в среде с прогнозируемыми показателями производительности.
Планирование вычислительной мощности не менее важно, чем архитектура; уделяйте первостепенное внимание этому вопросу независимо от того, имеется ли у вас под рукой специалист по аппаратной инфраструктуре или нет. Подобно тому как архитектор программного обеспечения отвечает за установление связей между потребностями и программным решением, архитектор аппаратной инфраструктуры отвечает за установление связей между аппаратной и программной частями.
Камал Викраманаяке (Kamal Wickramanayake) архитектор аппаратного и программного обеспечения, живет на Шри-Ланке. Является обладателем сертификата TOGAF от The Open Group.
«Срезание углов» сейчас обойдется слишком дорого потом Скот Макфи
Допустим, кто-то сказал вам, что модульные тесты не приносят непосредственной пользы, и вы даете своим разработчикам указание не углубляться в их создание. Впоследствии это значительно затруднит модификацию готовой системы и породит чувство неуверенности во внесенных изменениях. Относительно небольшие изменения потребуют гораздо большего объема ручного тестирования, что приведет к нестабильности и росту затрат на сопровождение, а получившийся дизайн нельзя будет назвать полностью тестируемым (не говоря уже о соответствии принципу «опережающего тестирования»).
Серьезной архитектурной ошибкой является и попытка приспособить существующую систему к тем целям, для которых она не предназначалась, под тем предлогом, что использование существующей системы может каким-то образом снизить затраты. Например, архитектурные компоненты BPEL в сочетании с триггерами баз данных можно приспособить для реализации системы на основе асинхронной передачи сообщений. Такие решения обычно возникают из соображений удобства либо потому, что эта архитектура известна вам или клиенту. Однако действительным основанием для такого выбора могут послужить только четко сформулированные требования это обязательное условие. Неудачные решения на ранней стадии проекта обходятся очень дорого, когда архитектуру системы приходится изменять в соответствии с новыми требованиями.
В начальной фазе разработки важно не только избегать «срезания углов», но и сразу исправлять неудачные проектировочные решения по мере их обнаружения. Отдельные плохо спроектированные аспекты системы могут лечь в основу других аспектов, что сделает последующие исправления еще более затратными.
Например, если вы поняли, что выбранные библиотеки плохо подходят для какой-то части функциональности системы, замените их как можно скорее.
автором справочника «WebLogic 6.1 Server Workbook for Enterprise JavaBeans, 3-е издание» (OReilly) и ведущим автором книги «Mastering WebLogic Server» (Wiley).
Остерегайтесь «хороших идей» Грег Найберг
Вы знаете, о каких хороших идеях я говорю: соблазнительные, очевидные, абсолютно безвредные на первый взгляд «ничего-страшного-не-будет-если-мы-попробуем». Обычно они приходят в голову кому-либо в команде где-то в середине жизненного цикла проекта, когда все вроде бы идет хорошо. Работа движется в бодром темпе, начальное тестирование проходит как положено, дата выпуска выглядит непоколебимой жизнь прекрасна.
Тут у кого-то появляется «хорошая идея», вы с ней соглашаетесь и вот вы уже переделываете проект под свежую версию Hibernate, чтобы воспользоваться ее новейшими возможностями, или используете AJAX на некоторых веб-страницах, потому что разработчик показал пользователям, как круто это смотрится, или пересматриваете архитектуру базы данных, чтобы задействовать те возможности по работе с XML, которые предлагает СУБД. Вы говорите руководителю проекта, что для реализации этой «хорошей идеи» понадобится еще несколько недель, однако изменения затрагивают больший объем кода, чем предполагалось, и график начинает трещать по швам. Вдобавок, приняв первую «хорошую идею», вы, как в поговорке, «выпустили джинна из бутылки»: вскоре на свет появляются новые «хорошие идеи», а вам уже гораздо труднее отказать (а джинн тем временем уже выглядывает из всех щелей).