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

Управление версиями исходного кода

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

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

Можно поставить два стула и программировать в паре, рассчитывая на рост продуктивности (см. врезку «Все встали парами!» на стр. 409). Но если три, четыре или более программистов попытаются одновре% менно работать с одним и тем же кодом, этот способ не подойдет.

•В другом варианте можно организовать совместный доступ к коду через файловый сервер. Тогда разные разработчики смогут видеть исходные файлы и даже редактировать их параллельно. Однако это далеко не идеальное решение. Код находится в общем доступе, но он не защищен, потому что два человека могут работать над одним и тем же файлом одновременно. В результате, когда они оба на% жмут кнопку Save, может произойти все, что угодно, в том числе потеря результатов работы. А что будет, если кто%нибудь отредак% тирует главный файл заголовков в тот момент, когда происходит сборка программы? Ответ: получится противоречивый исполняе% мый модуль, который станет аварийно завершаться или вести себя совершенно непредсказуемым образом.

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

1Об этом рассказывается в главе 12.

1Поэтому считается дурной практикой блокировать файл на слишком дли% тельное время – это может помешать работе других программистов. Это не%

отъемлемое ограничение такого метода доступа.

Рассказ бывалого человека

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

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

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

Контроль версий

Системы контроля за исходным кодом не просто хранят последнюю версию каждого файла. Хранилище записывает различие с предыду% щей версией при каждом сохранении файла. Имея эту важную инфор% мацию, можно получить любую версию файла за всю историю разра% ботки. Поэтому мы также пользуемся названием системы контроля версий (или модификаций). Это очень мощный инструмент: всякую модификацию можно целиком отменить – у вас в руках оказывается машина времени! Управление версиями в хранилище дает вам воз% можность:

•Отменять любые изменения, сделанные в любой момент.

•Следить за модификациями исходного кода, с которым вы работаете.

•Узнать, кто и когда изменял каждый файл (и даже выполнять сложные команды поиска, чтобы выяснить объем работы, проде% ланной над проектом отдельным разработчиком – полезно, когда разработка длится годами).

•Получить копию хранилища по состоянию на указанную дату.

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

Мания контроля версий

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

•Весь исходный код

•Среду для сборки

•Код для тестирования модулей и все средства для тестирования

•Любые другие файлы, необходимые для создания готового дистрибутива (графика, данные, настройки и пр.)

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

Но за чем дело стало? Можно расширить этот список и сделать его окончательно полным:

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

•Присоедините сюда всю документацию: спецификации, со% проводительные записки к версиям, руководства и т. д.