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

Родоначальницей всех систем управления версиями является SCCS (Source Code Control System), разработанная в Bell Labs в 1972 году. Ее заменила RCS (Revision Control System). Самая распространенная систе% ма в мире программного обеспечения с открытым кодом – CVS (Concur# rent Versions System), хотя она начала устаревать. CVS, основанная на базе RCS, дает возможность нескольким разработчикам работать над одним файлом одновременно. RCS реализует модель блокировки фай% лов (описанную в разделе «Жесткая блокировка» на стр. 450), тогда как CVS обеспечивает параллельную работу. Преемником CVS является система Subversion, в которой устранено большинство недостатков CVS.

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

Управление конфигурацией

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

Как мы видели, перед системой контроля за исходным кодом стоят следующие задачи:

•Обеспечить централизованное хранение кода

•Сохранить историю изменений, которым подверглись файлы

•Дать возможность разработчикам совместно трудиться, не создавая друг другу помех

•Дать возможность разработчикам решать задачи параллельно с по% следующим слиянием результатов

Основываясь на этом фундаменте, управление конфигурацией регули% рует разработку программного продукта на протяжении всего времени существования проекта. Оно включает в себя контроль за исходным кодом плюс процедуру разработки. Формально управление конфигу% рацией ПО определяется как «Порядок установления конфигурации системы в дискретные моменты времени с целью систематического контроля за изменениями в этой конфигурации и сохранения целост% ности и возможности слежения за этой конфигурацией на протяжении всего времени существования системы» (Bersoff et al. 80). Оно контро% лирует артефакты проекта (то, что вы помещаете в систему контроля за исходным кодом) и его процессы разработки.

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

Управление конфигурацией включает в себя:

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

Терминология и определения

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

Контроль за исходным кодом (source control)

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

Управление версиями (version control)

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

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

Управление конфигурацией

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

Распространены такие акронимы, как SCMS (система контроля за исходным кодом), VCS (система управления версиями) и RCS (система управления «ревизиями»).

Резервное копирование

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

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

Задумайтесь: есть ли резервная копия всего вашего кода? Меня ужас берет, когда я вижу, для какого огромного объема работы не выполне% но резервное копирование. Люди подвергают себя бессмысленному риску.

Делайте резервное копирование своих данных. Разработайте стратегию восстановления, не дожидаясь, когда грянет катастрофа.

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

промежуток времени между копированиями, или скопируете не то, что нужно. Вспомните закон Мерфи (на стр. 31): Если что#то может сломаться, оно сломается. Правильным будет поместить все важные файлы в файловую систему, которая участвует в резервном копирова% нии. Если я пользуюсь рабочей станцией, которая не участвует в ре% зервном копировании, я сохраняю свой код на сетевом файл%сервере, для которого делается резервная копия, а не оставляю на ненадежном локальном диске.1

Резервное копирование приносит пользу, если оно:

•Осуществляется регулярно

•Контролируется и проверяется

•Данные легко восстанавливаются

•Осуществляется автоматически (автоматически запускается и вы% полняется без вмешательства оператора)

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

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

Выпуск исходного кода

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

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

пережить.

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

Где я оставлю свой код…

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

Храните в тайне свои пароли регистрации. У посторонних (или злона% меренных коллег) не должно быть возможности причинить вам ущерб, воспользовавшись не принадлежащими им правами доступа.

Лицензии

Лицензия на программное обеспечение определяет, какие права

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

варенду и запуск на нескольких машинах. Напротив, лицензии open source защищают ваше право копировать и распространять программное обеспечение по своему желанию.

Авторы программ выбирают лицензии исходя из своих задач

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

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

Допустимые способы применения

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