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

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

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

Развивать код легче, если в компании принято разрабатывать про% граммное обеспечение путем небольших приращений (см. разделы «Итеративность» на стр. 322 и «Итеративная и инкрементная разра% ботка» на стр. 545). На этом пути эволюционирование оказывается ча% стью стратегии проектирования и переработка кода для интеграции изменений ожидается с самого начала. Альтернатива, когда монолит% ное здание кода требуется атаковать маленькой мотыгой и результат ожидается через 20 секунд, безрассудна, но не столь уж редка.

Как с этим бороться?

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

и мудрость, чтобы отличить одно от другого.

Рейнхольд Нибур

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

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

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

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

не происходит ни того, ни другого, а страдает программное обеспечение.

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

Как писать новый код

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

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

•Модульность и сокрытие информации (см. раздел «Модульность» на стр. 325) – это краеугольные камни современного программирова% ния. Ограничьте все предполагаемые изменения какой%то небольшой частью системы, что сделает ее более устойчивой к модификациям.

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

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

•KISS (Keep It Simple, Stupid – будь проще!). Не злоупотребляйте сложностью и техничностью. Оптимизируйте алгоритм, только ес% ли вы знаете, что он не обеспечивает нужной производительности, а не потому, что вы увидели способ сделать код более быстрым. Про% стота, как правило, более предпочтительна, чем эффективность, и несомненно, что она облегчает последующее сопровождение.

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

Сопровождение существующего кода

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

				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
375Click										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								376m
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
Глава 15. Программное обеспечение – эволюция или революция?Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

•История уже сделанных модификаций.

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

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

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

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

Не курочьте код бездумно. Остановитесь и поразмыслите, чем вы занимае& тесь.

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

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

в коде, с которым работаете (см. раздел «Сопровождение и бессо% держательные комментарии» на стр. 128).