hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Главаm		18. Защита исходного кода
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
665Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

Существует ли описание ваших функциональных обязанностей? Есть ли у вас список персональных задач? Если да, то занимаетесь ли вы их решением или этот список некорректен?

Глава 18. Защита исходного кода

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

1. Как надежно передать свой исходный код другим людям?

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

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

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

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

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

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

вредили, и чтобы взломщики не могли увидеть ваш код.

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

•Сделать тарбол (tarball) исходного дерева (создать архив из сжа% тых файлов – по имени команды UNIX tar). Этот архив можно пере% дать по почте, по FTP или на CD. Нужно лишь выбрать достаточно надежный метод.

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

2.Какая из двух моделей редактирования файлов в хранилище (блоки ровка загруженных файлов или их параллельная модификация) лучше?

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

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

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

•В параллельной модели такой проблемы нет и можно беспрепятст% венно продолжать кодировать в любой момент. Скрытая опасность заключается в возможности конфликтов между модификациями. Если Фред изменит в foo.c строки с 10 по 20, а Джордж – строки

с15 по 25, начинается гонка! У первого программиста, который со% хранит файл в системе, не возникнет никаких проблем, поэтому ес% ли победит Фред, в хранилище будет помещен его файл с изменен% ными строками с 10 по 20. Но когда Джордж попытается сохранить свою работу, система сообщит ему, что его дерево исходного кода устарело, и ему придется слить изменения, внесенные Фредом, со своим вариантом foo.c. Пять конфликтующих строк придется сли% вать вручную; Джордж должен будет дополнительно разбираться

сизменениями Фреда и пытаться объединить их со своими. Лишь после этого он сможет сохранить результаты своей работы.

Это не идеал, но на практике такое случается редко, и большинство конфликтов легко разрешается. Чаще всего случается так, что Фред модифицирует строки с 10 по 20, а Джордж – с 40 по 50; моди%

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Главаm		18. Защита исходного кода
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
667Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

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

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

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

•Наличие масштабируемой архитектуры клиент/сервер.

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

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

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

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

1Мартин Фаулер «Рефакторинг: улучшение существующего кода». – Пер.

с англ. – СПб: Символ%Плюс, 2002.

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

Вот хорошие критерии выбора системы управления исходным кодом:

Надежность

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

Емкость

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

Гибкость

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

Ветвление

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

Платформы

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

Стоимость и лицензирование

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

Аудит

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