А затем обычно наступает момент, когда архитектурная метафора вдруг становится опасной и восстает против своих создателей. Вот как это может происходить:
Ваша метафора начинает нравиться заказчику больше, чем сама разрабатываемая система, то есть все заинтересованные стороны начинают верить в красивую иллюзию, созданную метафорой, не желая разбираться, что за ней на самом деле скрывается.
Пример: «Мы строим транспортную систему по принципу перемещения корабля между несколькими причалами».
Вы представляете себе контейнеровоз, бороздящий просторы Тихого океана, я же имел в виду гребную лодку в бассейне, притом с одним веслом.
Команда разработчиков начинает считать метафору более весомой по сравнению с реальной бизнес-задачей. А вы из любви к своей метафоре начинаете оправдывать странные решения.
Пример: «Мы сказали, что система будет похожа на картотечный шкаф, поэтому нам придется выводить данные в алфавитном порядке. Я знаю, что этот шкаф имеет шесть измерений, бесконечную длину и встроенные часы,
путать догматизм с качественным управлением. Вместо этого следует задать вопросы: Почему эти свойства так необходимы? Какие преимущества они приносят? Когда они желательны? Как разбить систему на части для достижения лучшего результата? В таких случаях всегда проявляйте здоровый скепсис, потому что архитектурные догмы способны сделать поставку продукта проблематичной. Принять неизбежность таких компромиссов одна из самых трудных задач в разработке программного обеспечения, причем не только для архитекторов, но также для разработчиков и других заинтересованных лиц. И все же это гораздо лучше, чем иметь безграничную свободу выбора, неизбежные компромиссы часто ведут к творческим, нестандартным результатам.
Билл де Ора (Bill de hÓra) ведущий архитектор в компании NewBay Software, где он работает над крупномасштабными веб-системами и системами для мобильных устройств. Является соредактором Atom Publishing Protocol, ранее участвовал в работе группы W3C RDF Working Group. Признанный эксперт в области REST и архитектур на основе передачи сообщений, а также проектирования протоколов.
Принципы, аксиомы и аналогии важнее личных мнений и предпочтений Майкл Хармер
Прежде всего, упростится документирование архитектуры. Вы можете начать с описания принципов, использованных при проектировании. Это гораздо проще, чем пытаться изложить свое личное мнение и опыт. Описанные принципы станут удобной отправной точкой для тех, кому предстоит разобраться в вашей архитектуре и реализовать ее. Кроме того, такое описание окажет бесценную помощь начинающим архитекторам, которые будут работать с вашей архитектурой.
Четкое изложение принципов избавляет архитектора от необходимости лично участвовать во всех процессах, для которых архитектура системы является определяющим элементом. Это изложение расширяет возможности и влияние архитектора. Вам необязательно становиться вездесущим трудоголиком, чтобы другие без особых трудностей смогли:
Реализовать и адаптировать архитектуру
Расширить архитектуру на смежные предметные области
Модифицировать архитектуру для реализации с использованием новых технологий
Подробно проработать граничные случаи
Расхождения во мнениях и вкусах неизбежно переходят в политические споры, в которых побеждает тот, кто обладает властью. Напротив, несогласие с ясными основополагающими принципами ведет к конструктивной дискуссии без переходов на личности. Более того, появляется возможность разрешить спорные моменты вообще без обращения к архитектору.
Принципы и аксиомы обеспечивают также согласованность архитектуры как в ходе реализации, так и в дальнейшем. Поддержание согласованности часто становится серьезной проблемой, особенно в крупных системах, охватывающих несколько технологий и существующих в течение многих лет. Четко сформулированные архитектурные принципы помогут человеку, незнакомому с конкретной технологией или компонентом, быстрее разобраться в новой области и понять ее.
Майкл Хармер (Michael Harmer) занимается разработкой программного
Мы, разработчики, изначально воспринимаем программное обеспечение как систему команд, функций и алгоритмов. Такое «командно-ориентированное» представление помогает нам освоить построение ПО, но оно же начинает мешать, когда мы пытаемся создавать более масштабные системы.
В конце концов, компьютер не что иное, как хитроумный инструмент, который помогает нам получать и обрабатывать горы данных. Структура этих данных лежит в основе нашего понимания того, как справиться со сложностью крупномасштабной системы. Миллионы команд сложны по своей природе, однако за ними стоит небольшой набор базовых структур данных, который мы можем легко понять.
Например, если вы хотите разобраться в операционной системе UNIX, вряд ли вам сильно поможет построчный просмотр ее исходного кода. Но если вы прочитаете книгу, которая описывает основные внутренние структуры данных, обеспечивающих работу процессов, файловых систем и т. д., вы скорее поймете глубинные принципы работы UNIX. Концептуально структуры данных имеют гораздо меньший размер и существенно более просты по сравнению с кодом.