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

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

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

• Реализовать и адаптировать архитектуру

• Расширить архитектуру на смежные предметные области

• Модифицировать архитектуру для реализации с использованием новых технологий

• Подробно проработать граничные случаи

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

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

Майкл Хармер (Michael Harmer) занимается разработкой программного обеспечения уже 16 лет. Он был рядовым разработчиком, руководителем группы, архитектором, ведущим специалистом и руководителем направления.

Чрезвычайно полезная стратегия реализации, проверки и совершенствования архитектуры приложения — начать с того, что Алистер Коберн (Alistair Cockburn) называет ходячим скелетом. Речь идет о минимальной реализации системы «от начала до конца», связывающей воедино все основные архитектурные компоненты. Начав с минимума — с рабочей системы, содержащей все коммуникационные каналы, — вы можете быть уверены в том, что движетесь в правильном направлении.

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

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

Чем крупнее система, тем важнее использовать эту стратегию. В небольшом приложении всю функциональность от начала до конца может относительно быстро реализовать один разработчик, но в более крупных системах такой подход становится непрактичным. Достаточно часто встречается ситуация, когда в реализации заняты несколько разработчиков из одной команды (и даже нескольких распределенных команд). Соответственно необходима более тесная координация. К тому же разработчики выдают результаты в разном темпе: одни успевают сделать много за небольшой промежуток времени, другие тратят уйму времени на небольшую задачу. Самые сложные и трудоемкие задачи должны выполняться на ранней стадии проекта.

Начните со скелета, заставьте его ходить, а затем постепенно наращивайте на него плоть.

Клинт Шенк (Clint Shank) — разработчик, консультант и преподаватель из Sphere of Influence, Inc., компании, предоставляющей услуги по проектированию и производству программных продуктов коммерческим и правительственным организациям.

Мы, разработчики, изначально воспринимаем программное обеспечение как систему команд, функций и алгоритмов. Такое «командно-ориентированное» представление помогает нам освоить построение ПО, но оно же начинает мешать, когда мы пытаемся создавать более масштабные системы.

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

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