hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Хорошийm		проект программного продукта
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
321Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

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

Код, который основан на прочном проекте:

•Проще написать (есть четко определенный план действий, и ясно, как собрать вместе отдельные части)

•Легко понять

•Проще исправлять (можно определить, в каком месте гнездится проблема)

•С меньшей вероятностью содержит ошибки (ошибки в программе не скрываются за таинственными проблемами проектирования)

•Более устойчив к изменению (проект поддерживает расширения и модификацию)

Хороший проект программного продукта

Любая задача программирования допускает несколько вариантов про% екта кода. Вы должны выбрать из них один. Лучший. Или хотя бы достаточно хороший. Это не так просто…

•Как определить, что ваш проект жизнеспособен? Выработав безу% пречный план проведения атаки, вы уверенно приступаете к его реализации. Через какое%то время вы сталкиваетесь с неожиданной проблемой. Назад к чертежной доске!

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

Только опробовав некоторое решение, вы по%настоящему начинаете

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

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

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

Лучшие подходы к проектированию учитывают эти проблемы. Пере% числим их:

Итеративность

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

Осторожность

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

Реализм

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

Осведомленность

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

На ваш подход к проектированию неизбежно повлияет действующая общая методология разработки (см. их описание в разделе «Стили про% граммирования» на стр. 530). Правильная процедура проектирования – это шаг в направлении создания хорошего проекта, но не гарантия его. Все равно все сводится к качеству принимаемых вами проектных ре% шений. Выбор различных компромиссов ведет к различным проектам. Например, проект, ориентированный на скорость, будет отличаться от проекта, ориентированного на расширяемость. В конце концов, не бы%

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Хорошийm		проект программного продукта
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
323Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

вает правильных и неправильных проектов. В лучшем случае есть хо# рошие проекты и плохие проекты.

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

Простота

Это главнейшая характеристика хорошо спроектированного кода. Если проект прост, его легко понять, в нем нет излишеств или пороков и его легко реализовать. Ему свойственны связность и последовательность.

Простой код мал по объему, насколько это возможно. Это требует опре% деленного труда. Блез Паскаль писал: «Прошу извинить, что мое письмо получилось таким длинным, но у меня не было времени сде% лать его короче». Постарайтесь выяснить, каким самым коротким ко% дом можно обойтись, и не добавляйте ничего лишнего к нему. Запом% ните, что потом всегда можно будет дописать новые функции, но труд% но будет удалить то, что обросло связями.

Лень иногда бывает оправданна. Делайте проект так, чтобы как можно больше работы отложить на последний момент, и сосредоточьтесь на непосредственных задачах.

Чем меньше, тем лучше. Вашей целью должен быть простой код, который при малом размере решает большие задачи.

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

Сделать простую вещь сложно. Если структура кода кажется очевидной, не надо думать, что это далось без труда.

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

Элегантность

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

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

Поиск компромисса

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

Вот типичные примеры такого перетягивания канатов:

Расширяемость против простоты

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

Эффективность против безопасности

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

Однако не всегда эффективные проекты оказываются плохи% ми; у многих хороших проектов производительность оказы% вается высока благодаря простоте.

Функциональность против объема работ

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

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

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

•Все части дополняют одна другую, внося что%то индивидуальное

и ценное.