Прогресс цивилизации состоит в расширении сферы действий, которые мы выполняем не думая.
На заре автомобильной эры инструкция по запуску автомобиля «Форд-Т» составляла две с лишним страницы. В современных автомобилях достаточно лишь повернуть ключ – процедура запуска является автоматической и надежной. Водитель, действующий по инструкции, может «залить» свечи зажигания, а автоматический стартер подобного не допустит.
Хотя информатика все еще напоминает автопромышленность времен выпуска модели «Форд-Т», мы не можем позволить себе в обычной работе раз за разом выполнять набор инструкций, расположенный на двух страницах. Неважно, что это – процедура сборки и выпуска готовой версии, рассмотрение текста программы или же любая повторяющаяся задача, возникающая в ходе проекта, – все это должно выполняться автоматически. Возможно, нам придется изготовить стартер и топливный инжектор "с нуля", но как только это будет сделано, с этого момента будет достаточно лишь повернуть ключ зажигания.
Мы хотим также гарантировать полноту и повторяемость при работе над проектом. Выполняемые вручную процедуры не гарантируют полноту; повторяемость также не гарантируется, особенно если аспекты конкретной процедуры открыты для интерпретации другими людьми.
Все в автоматическом режиме
Однажды мы посетили фирму-заказчик, где все разработчики использовали одну и ту же интегрированную среду разработки. Их системный администратор снабжал каждого разработчика набором инструкций по установке добавочных средств для этой среды. Эти инструкции занимали много страниц – 'щелкни мышью здесь, прокрути туда, отбуксируй это, щелкни здесь мышью два раза, повтори".
Не удивительно, что компьютер у каждого разработчика загружался по-своему. Когда разные разработчики прогоняли одну и ту же программу, в поведении приложения проявлялись малозаметные отличия. Дефекты возникали на одной машине, а на других все было нормально. При прослеживании разницы в версиях любого из компонентов обычно выявлялись неожиданные вещи.
Подсказка 61: Не используйте процедуры, выполняемые вручную
В отличие от компьютеров, люди не обладают повторяемостью в своих действиях. Мы этого от них и не ждем. Сценарий оболочки или пакетный файл выполнят те же самые инструкции, в том же порядке, раз за разом. Он может отслеживаться системой управления исходным текстом, так что возможно изучать изменения в процедуре и по прошествии времени ("но ведь она всегда работала… ").
Другим излюбленным средством автоматизации является cron (или «at» в системе Windows NT). Он позволяет планировать периодический прогон задач без участия пользователя – обычно этот прогон делается ночью. Например, представленный ниже файл crontab указывает, что команда nightly, используемая в проекте, должна запускаться каждый день в 00:05, что процедура резервного копирования backup должна запускаться в 03:15 по будням и что команда expense_eports должна выполняться в полночь первого числа каждого месяца.
С помощью cron можно планировать процедуры резервного копирования, сопровождение web-сайтов и любых других операций, которые нужно проводить без участия пользователя, т. е. автоматически.
Компилирование проекта
Компилирование проекта – это работа, которая должна быть надежной и повторяемой. Обычно проекты компилируются с помощью файлов сборки даже в интегрированной среде разработчика. В использовании файлов сборки есть ряд преимуществ. Это подготовленная по сценарию автоматическая процедура. Можно добавлять специальные программные процедуры для генерации текста программы и запускать регрессионные тесты в автоматическом режиме. Интегрированные среды имеют свои преимущества, но, пользуясь только ими, бывает трудно добиться нужного уровня автоматизации. Мы хотим осуществлять проверку, сборку, тестирование и передачу программы заказчику с помощью одной-единственной команды.
В разделе "Пороки дублирования" мы призываем к генерированию текстов программ для получения знания из обычных источников. Для облегчения этого процесса мы можем задействовать механизм анализа зависимости в программе 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).
Для большинства проектов этот этап сборки осуществляется автоматически каждую ночь. «Ночная» сборка обычно выполняет больше полных тестов, чем отдельный сотрудник при сборке определенной части проекта. Важным моментом является то, что при полной сборке должны запускаться все тесты, имеющиеся в наличии. Вы хотите убедиться в том, что программа не прошла регрессионный тест вследствие изменений, которые были сделаны в программе сегодня. Идентифицируя проблему ближе к источнику, вы с большей вероятностью сможете отыскать и устранить существующую проблему.