hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Главаm		13. Важность проектирования
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
643Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

На каждого может кто%нибудь напасть: злонамеренный пользователь, беспринципные конкуренты и даже террористы. Разве можно кому%то верить?

Глава 13. Важность проектирования

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

1.Как масштаб всей задачи влияет на проект программного обеспечения и работу по его созданию?

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

2.Что лучше – хорошо документированный плохой проект или плохо до кументированный хороший проект?

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

Если код достаточно простой, вам не потребуется объемистая докумен% тация, но если программа сложная, работать с ней в отсутствие при% личного описания становится трудно.

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

3.Как оценить качество проекта по фрагменту кода? Можно ли количе ственно отразить его простоту, элегантность, модульность и т. п.?

Качество трудно измерить; в значительной мере это эстетическая оцен% ка проекта. Почему мы считаем картину прекрасной? Это из разряда тех вещей, которые нельзя взять в руки и пересчитать. Задним числом вы можете оценить, насколько просто оказалось разобраться в коде или модифицировать его. Но впервые столкнувшись с каким%то кодом, трудно его оценить. Если есть две архитектуры, A и B, и мне кажется, что A красивее, но на практике B оказывается удобнее и легче допуска% ет модификацию, то трудно утверждать, что архитектура A лучше.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								644m
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.Может ли проектирование быть коллективной деятельностью? На сколько важны навыки групповой работы при разработке хорошего проекта?

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

5.Есть ли зависимость между проектом и наиболее предпочтительной для него методологией?

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

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

6.Каким образом можно определить, является ли данный проект сильно связным или слабо сцепленным?

В конечном счете нужно смотреть на код и выяснять, как он связан внутри себя, но это так скучно! Для проекта на C или C++ можно оце% нить степень его связанности, посмотрев на директивы #include в нача% ле файла. Если они многочисленны, то связанность может быть умопо% мрачительной. С другой стороны, можно воспользоваться программа% ми анализа, которые наглядно отобразят свойства вашего кода.

7.Если вам приходилось решать аналогичную задачу проектирования

впрошлом, поможет ли это определить, насколько сложна проблема

вданном случае?

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Главаm		13. Важность проектирования
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
645Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

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

8. Допустимы ли эксперименты в проектировании?

Да, все проекты экспериментальные, пока они не реализованы и не признаны успешными. Возьмите принцип «первый раз делай на вы% брос», описанный Фредериком Бруксом (Brooks 95). В пользу экспери% ментирования можно сказать многое.

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

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

1.Обратитесь к прошлому и вспомните, как вы учились проектировать код. Смогли бы вы передать полученные вами знания абсолютному но вичку в этом деле?

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

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

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

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

Остался ли у вас неприятный осадок от прежнего опыта и предпочте% ний? Если вы не умеете применять какую%то методологию, вам будет тяжело и неуютно работать с ней. Матерый C%программист вполне мо% жет невзлюбить любые объектно%ориентированные проекты, а его соб% ственные ОО%конструкции окажутся ужасными. Но это не значит, что OO%программирование – неправильный подход.