hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								646m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Ответы и обсуждениеClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

3.Считаете ли вы, что нужно строго придерживаться выбранной методо логии?

Метод проектирования – это инструмент, приспособление. Как и язы% ком проектирования, им следует пользоваться до той поры, пока он со% храняет полезность. Если он перестает быть полезным, это уже не ин% струмент! Методология окажется бездейственной, если никто в вашей команде не будет знать, как ее применять; пользуйтесь тем, что всем известно, или сначала научите их новому.

4.Какой код из тех, что вам встречались, был спроектирован лучше все го? Хуже всего?

Я думаю, что вам нетрудно будет вспомнить, какой код был хуже всего спроектирован. Плохой код не дает забыть о себе, как больное место. Хорошо спроектированный код выглядит просто и очевидно, не вызы% вая желания воскликнуть: «Какой замечательный проект!». Возмож% но, вы даже не обратите внимания на то, сколько сил потребовало его проектирование.

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

Очень важным, иначе получится никому не понятный код.

Некоторые архитектурные решения могут определяться языком, но на код низкого уровня язык реализации оказывает огромное влияние. Очевидный пример: при кодировании на Java не пользуйтесь плоской процедурной архитектурой – это абсолютно ошибочно.

6.Считаете ли вы программирование технической дисциплиной, ремес лом или искусством?

Если говорить просто, все зависит от того, как этим заниматься. В нем есть элементы одного, другого и третьего.

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

Глава 14. Программная архитектура

Вопросы для размышления

1.Объясните, где заканчивается архитектура и начинается проекти рование программного продукта.

По правде говоря, то и другое можно определить так, как вам больше нравится. В стандартном употреблении есть следующие различия:

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Главаm		14. Программная архитектура
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
647Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

•Архитектура – проект структуры верхнего уровня. Она учитывает далеко идущие последствия выбранных решений, влияющие на стоимость создания и сопровождения, общую сложность системы, возможности расширения в будущем и задачи маркетинга. Архи% тектура разрабатывается в начале проекта. Она оказывает значи% тельное влияние, по крайней мере, на последующее проектирова% ние программного продукта.

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

Точная граница между тем и другим отчасти определяется масштабом проекта. Создание программного продукта является итеративным и инкрементным процессом – хотя вначале разрабатывается архитек% тура, результаты проектирования продукта могут оказать обратное влияние на архитектуру.

2.Как плохая архитектура может сказаться на качестве системы? Есть ли такие части, на которые недостатки архитектуры не оказывают влияния?

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

3. Трудно ли исправить выявившиеся недостатки архитектуры?

На ранних этапах формирования продукта относительно легко воздей% ствовать на архитектуру. Но когда в соответствии с этой архитектурой началась разработка и в жертву ей принесен определенный объем ка% питаловложений (в смысле проектирования и кодирования), весьма и весьма трудно что%либо изменить. С таким же успехом можно попы% таться переписать с самого начала весь продукт.

Вот почему так важно с самого начала правильно определить архитек% туру. Рефакторингу можно подвергнуть небольшие участки кода, но не все основание структуры.

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

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								648m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Ответы и обсуждениеClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

4.В какой мере архитектура оказывает влияние на:

a.Конфигурацию системы

b.Ведение журналов

c.Обработку ошибок

d.Безопасность

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

a.Архитектура определяет, что можно конфигурировать (в каком объеме) и как это делать. Тип механизма конфигурации определя% ется рядом факторов: значением общей компоненты «администра% тора конфигурации», необходимостью в удаленном конфигуриро% вании и определением лиц, которым разрешено конфигурирование (только разработчикам или также тем, кто устанавливает, сопрово% ждает или эксплуатирует систему). Все это фундаментальные про% блемы архитектуры.

b.Отдельные компоненты могут заносить информацию в журнал с по% мощью общего механизма или индивидуальных средств. Архитек% тура определяет, какой из способов предпочтительнее, как полу% чать доступ к журналам и какая информация нуждается в регист% рации. Она должна учитывать требования как разработчиков, так и пользователей. Должны ли окончательные версии вести журнал данных для разработчика?

c.Аспекты архитектуры, относящиеся к обработке ошибок, включа% ют в себя наличие или отсутствие центрального сервиса регистра% ции ошибок в журнале и системы сообщений об ошибках (каким об% разом ошибка проникает из жалких серверных компонент в сте% рильный графический интерфейс пользователя?). В архитектуре также определяется тип механизма обработки ошибок: централь% ная таблица кодов ошибок, общих для всех компонент, или общая иерархия исключений. Решается и проблема обработки ошибок, ге% нерируемых компонентами сторонних разработчиков.

d.Проблемы безопасности зависят от типа разрабатываемого про% граммного обеспечения. У распределенной системы торговых то% чек, использующей для связи Интернет, будет иная система требо% ваний к защите, чем у маленькой программы, размещаемой на от% дельном компьютере. Безопасность – важный вопрос, и ее нельзя присоединить к системе в последний момент; эти проблемы нужно

решать на ранних стадиях проектирования архитектуры.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Главаm		14. Программная архитектура
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
649Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

5.Какой опыт или подготовка необходимы для того, чтобы называться

программным архитектором?

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

Хорошие архитектурные разработки требуют наличия богатого опыта – изучения, проектирования и доработки программных систем. Приоб% рести его можно только в результате самостоятельного труда, а не на% блюдения за работой других. Следует с опасением относиться к тем, кто начинает называть себя архитектором, выпустив единственную версию продукта.

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

6.Должна ли стратегия рыночного поведения оказывать влияние на ар хитектуру? Если да, то каким образом? Если нет, то почему?

Да, коммерческие соображения обязательно влияют на архитектуру. В противном случае система, которую вы построите, окажется нежиз% неспособным продуктом; вы быстро станете безработным, а ваша ком% пания – несостоятельным должником.

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

Коммерческие соображения влияют также на такие области архитек% туры, как средства поддержки клиентов (в частности, определяя сте% пень сложности администрирования системы), метод установки (с по% мощью обученного персонала или автоматически с CD), техническое обслуживание и система оплаты.

7.Какими особенностями должна обладать архитектура, рассчитанная на расширение? А рассчитанная на максимальную производительность? Какое влияние эти проектные цели оказывают на систему и в каких отношениях они находятся между собой?

Есть несколько архитектурных решений, которые вытекают из этих двух требований:

•Расширяемость достигается с помощью таких архитектурных средств, как подключаемые модули (плагины), программный до% ступ к коду (отражение), дополнительные языковые связки, сред%

ства написания сценариев и дополнительные уровни косвенности.