Компилирование проекта

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

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

.SUFFIXES: .Java .class .xml

.xml.java:

    perl convert.pl $<>$@

.java.class:

   $(JAVAC) $(JAVAC_FLAGS) $<

Наберем make test.class, и программа make автоматически найдет файл с именем test.XML, сформирует файл. Java, выполнив сценарий Perl, а затем скомпилирует этот файл, создав test.class.

Можно использовать подобные правила также для автоматической генерации исходного текста, файлов заголовка или документации из иной формы (см. "Генераторы исходных текстов").

Можно воспользоваться файлом сборки для прогона либо регрессионных тестов, либо отдельного модуля, либо подсистемы в целом. Вы легко можете протестировать весь проект целиком при помощи одной-единственной команды на вершине исходного дерева или же протестировать отдельный модуль, воспользовавшись той же командой в единственном каталоге. Более подробно регрессионное тестирование рассматривается в разделе "Безжалостное тестирование".

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

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

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

Автоматизация процесса сборки

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

1. Исходный текст программы извлекается из архива.

2. Проект формируется с нуля, обычно из файла сборки верхнего уровня. Каждая сборка помечается определенным номером выпуска/версии или отметкой даты.

3. Создается копия для распространения. Эта процедура может повлечь за собой фиксирование права собственности на файл и разрешения на его использование, создание всех примеров, документации, файлов README и всего того, что будет отправлено вместе с готовым продуктом именно в том формате, который требуется при передаче заказчику [46] .

4. Проведите указанные тесты (процедура make test).

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

Если вы не проводите регулярное тестирование, то можете обнаружить, что приложение не работает вследствие изменения, внесенного три месяца назад. Удачи вам – в поиске этого изменения.

Окончательные сборки, которые вы намереваетесь отправить заказчику в виде готовых продуктов, могут предъявлять требования, отличающиеся от регулярной «ночной» сборки. Окончательная сборка может требовать, чтобы библиотека исходных файлов была заблокирована или снабжена номером выпуска, чтобы флаги оптимизации и отладки были установлены по-другому и т. д. Мы предпочитаем использовать отдельный рабочий файл make (типа make final), который устанавливает все эти параметры сразу.

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

Автоматические административные процедуры

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

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

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

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

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