hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								650m
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

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

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

Вопросы личного характера

1.Насколько широк диапазон архитектурных стилей, которые вы при меняете в своей работе? В каком из них у вас больше опыта и как это влияет на программы, которые вы пишете?

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

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

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

Во%первых, нужно определить, какую архитектуру считать успешной. Значит ли это, что у нее есть технические достоинства? Или система оказалась коммерчески выгодной? Или то и другое вместе? У вас мо% жет быть свой собственный ответ.

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

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

				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
651Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

во. При переработке продукта всегда нужно помнить уроки предшест% вующих версий.

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

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

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

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

4.Есть ли в вашем текущем проекте общедоступное описание архитекту ры? Давно ли оно обновлялось? Какими видами представления вы пользуетесь? Если вам потребуется рассказать о системе новому со труднику или будущему клиенту, какие данные вам реально потребо вались бы в документе?

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

5.Сравните архитектуры своей системы и ваших конкурентов. Благода ря каким особенностям своей архитектуры вы рассчитываете добить ся успеха своего проекта?

Необходимо понимать, какие особенности вашей архитектуры долж% ны обеспечить выполнение всех технических требований и гарантиро% вать успех. (Если вы руководствовались при ее разработке какими%то