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

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

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

Глава 15. Программное обеспечение – эволюция или революция?

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

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

Никакая. Бессмертные слова Фореста Гампа: «Программа – это то, что ведет себя как программа». (Groom 94) Создание кода вызывает много ассоциаций, но ни одна метафора не передает все тонкости, как нельзя передать словами красоту восхода солнца.

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

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

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

•зачатие

•рождение

•рост

•созревание

•выход в мир

•средний возраст

•усталость

•выход на пенсию

•смерть

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Главаm		15. Программное обеспечение – эволюция или революция?
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
653Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

Зачатие

Компания видит нишу для нового продукта. Определяются требо% вания рынка к нему. Принимается решение о разработке.

Рождение

Запускается программный проект. Привлекаются проектировщики и программисты. Определяется архитектура. Начинают писать код.

Рост

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

Созревание

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

Выход в мир

Выходит версия программы 1.0. Она успешно удовлетворяет по% требностям рынка.

Средний возраст

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

Усталость

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

Выход на пенсию

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

Смерть

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

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								654m
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.Важно ли обеспечить обратную совместимость при сопровождении кода?

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

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

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Главаm		15. Программное обеспечение – эволюция или революция?
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
655Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

6.В каком случае деградация кода происходит быстрее – при его моди фикации или сохранении в неизменном состоянии?

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

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

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

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

1.Чем вам больше приходится заниматься – написанием нового кода или модификацией имеющегося?

a.Если это новый код, то пишется ли он для вновь создаваемых сис тем или расширений существующих?

b.Зависит ли от этого, как вы пишете код? Каким образом?

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

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

2.Есть ли у вас опыт работы с уже готовым базовым кодом? Если да:

a.Повлияло ли это на ваш нынешний уровень мастерства? Чему вы в результате научились?

b.Каким был этот код по большей части – плохим или хорошим? Ка ким образом вы это оценивали?

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

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								656m
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.Через сколько ревизий прошел код вашего текущего проекта?

a.В какой мере менялась функциональность от одной версии к дру гой? Как менялся код?

b.Осуществлялось ли развитие наудачу, по плану или каким то про межуточным образом? В чем это проявляется сейчас?

Вот несколько важных соображений.

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

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

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