Вездесущая автоматизация
Прогресс цивилизации состоит в расширении сферы действий, которые мы выполняем не думая.
На заре автомобильной эры инструкция по запуску автомобиля «Форд-Т» составляла две с лишним страницы. В современных автомобилях достаточно лишь повернуть ключ – процедура запуска является автоматической и надежной. Водитель, действующий по инструкции, может «залить» свечи зажигания, а автоматический стартер подобного не допустит.
Хотя информатика все еще напоминает автопромышленность времен выпуска модели «Форд-Т», мы не можем позволить себе в обычной работе раз за разом выполнять набор инструкций, расположенный на двух страницах. Неважно, что это – процедура сборки и выпуска готовой версии, рассмотрение текста программы или же любая повторяющаяся задача, возникающая в ходе проекта, – все это должно выполняться автоматически. Возможно, нам придется изготовить стартер и топливный инжектор «с нуля», но как только это будет сделано, с этого момента будет достаточно лишь повернуть ключ зажигания.
Мы хотим также гарантировать полноту и повторяемость при работе над проектом. Выполняемые вручную процедуры не гарантируют полноту; повторяемость также не гарантируется, особенно если аспекты конкретной процедуры открыты для интерпретации другими людьми.
Все в автоматическом режиме
Однажды мы посетили фирму-заказчик, где все разработчики использовали одну и ту же интегрированную среду разработки. Их системный администратор снабжал каждого разработчика набором инструкций по установке добавочных средств для этой среды. Эти инструкции занимали много страниц – 'щелкни мышью здесь, прокрути туда, отбуксируй это, щелкни здесь мышью два раза, повтори».
Не удивительно, что компьютер у каждого разработчика загружался по-своему. Когда разные разработчики прогоняли одну и ту же программу, в поведении приложения проявлялись малозаметные отличия. Дефекты возникали на одной машине, а на других все было нормально. При прослеживании разницы в версиях любого из компонентов обычно выявлялись неожиданные вещи.
Подсказка 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).
Для большинства проектов этот этап сборки осуществляется автоматически каждую ночь. «Ночная» сборка обычно выполняет больше полных тестов, чем отдельный сотрудник при сборке определенной части проекта. Важным моментом является то, что при полной сборке должны запускаться все тесты, имеющиеся в наличии. Вы хотите убедиться в том, что программа не прошла регрессионный тест вследствие изменений, которые были сделаны в программе сегодня. Идентифицируя проблему ближе к источнику, вы с большей вероятностью сможете отыскать и устранить существующую проблему.
Если вы не проводите регулярное тестирование, то можете обнаружить, что приложение не работает вследствие изменения, внесенного три месяца назад. Удачи вам – в поиске этого изменения.
Окончательные сборки, которые вы намереваетесь отправить заказчику в виде готовых продуктов, могут предъявлять требования, отличающиеся от регулярной «ночной» сборки. Окончательная сборка может требовать, чтобы библиотека исходных файлов была заблокирована или снабжена номером выпуска, чтобы флаги оптимизации и отладки были установлены по-другому и т. д. Мы предпочитаем использовать отдельный рабочий файл make (типа make final), который устанавливает все эти параметры сразу.
Помните, что если компиляция продукта отличается от компиляции предыдущей версии, то вы обязаны провести тестирование согласно этой версии заново.
Автоматические административные процедуры
Наверное, было бы недурно, если бы программисты могли реально посвящать все свое время программированию. К сожалению, это бывает очень редко. Нужно отвечать на сообщения электронной почты, выполнять бумажную работу, помещать документы в Интернет и т. д. Вы можете решиться на создание сценария оболочки, который будет делать всю грязную работу, но не забывайте запускать этот сценарий, когда необходимо.
Поскольку память – это вторая по счету вещь, которую мы теряем с возрастом [47], мы не хотим полагаться на нее слишком сильно. Мы можем запускать сценарии, которые будут выполнять для нас процедуры в автоматическом режиме, основываясь на содержимом исходного текста программы и документов. Наша цель состоит в том, чтобы поддерживать автоматическую, не требующую вмешательства пользователя последовательность операций содержательного характера.
Многие команды разработчиков используют внутренний web-сайт для обмена информацией в ходе выполнения проекта, и мы полагаем, что это прекрасная идея. Но мы не хотим тратить много времени на поддержку web-сайта и не желаем, чтобы информация, содержащаяся на нем, устаревала. Информация, вводящая в заблуждение, хуже, чем отсутствие какой бы то ни было информации вообще.
Документация, извлекаемая из программы, анализа требований, проектных документов и любых чертежей, графиков или диаграмм, должна регулярно публиковаться на web-сайте. Мы предпочитаем публиковать эти документы автоматически – это является частью ночной процедуры сборки или добавочным блоком в процедуре возвращения исходного текста программы в библиотеку.
Однако если это сделано, содержание web-сайта должно генерироваться автоматически из информации, хранящейся в централизованной библиотеке, и публиковаться без вмешательства человека. На самом деле это еще одно применение принципа DRY: информация существует в одной форме – в виде исходного текста и документов в библиотеке. При просмотре с помощью web-браузера они так и выглядят – просто визуальное представление. Вам не придется поддерживать это представление вручную.
Любая информация, сгенерированная в процессе ночной сборки, должна быть доступна на web-сайте разработчиков: результаты самой сборки (они могут быть представлены в виде краткого отчета на одной странице, содержащего предупреждения компилятора, ошибки и текущее состояние), регрессионные тесты, рабочая статистика, программные метрики, а также любые другие результаты статического анализа и т. д.
Некоторые проекты участвуют в административном документообороте, требования которого необходимо соблюдать. Например, рассмотрение проекта или текста программы должно быть спланировано и доведено до конца, документы необходимо утверждать и т. д. Можно использовать автоматизацию и – особенно это касается web-сайта – облегчить бремя, налагаемое бумажной работой.
Предположим, что вы хотели автоматизировать планирование рассмотрения и процедуру утверждения текста программы. В каждый файл с исходным текстом вы могли бы поместить специальный маркер:
/* Status: needs_review */
Простой сценарий должен пройти весь исходный текст до конца и провести поиск всех файлов, находившихся в состоянии needs_review, которое указывало на их готовность к рассмотрению. Затем вы могли бы поместить список этих файлов в виде web-страницы, автоматически послать электронную почту соответствующим адресатам или даже назначить встречу, используя программу календарного планирования.
Вы можете организовать некую форму на web-странице, чтобы рецензенты регистрировали свое утверждение или несогласие. После рассмотрения состояние может быть автоматически изменено на reviewed. Использовать или не использовать сквозной контроль текста программы всеми участниками – это зависит от вас; всю бумажную работу вы можете проделывать автоматически независимо от этого. (В своей статье в журнале САСМ (апрель 1999 г.) Роберт Гласе обобщает результаты исследования, которое, похоже, указывает на то, что критическое рассмотрение текста программы отличается эффективностью, в отличие от рассмотрения в ходе собраний [Gla99a].)
Дети сапожника
Дети сапожника всегда без сапог. Зачастую те, кто занимается разработкой программ, используют наихудшие инструментальные средства для выполнения своей работы.
Но у нас имеются все исходные материалы для того, чтобы создать лучшие инструменты. У нас есть программа cron. У нас есть программа make для платформ Windows и Unix. У нас есть и Perl, а также другие языки сценариев высокого уровня для быстрой разработки заказных инструментальных средств, генераторов web-страниц, исходных тестов программ, тестовых стендов и т. д.
Пусть компьютер делает скучную земную работу – он сделает это лучше, чем мы. У нас есть задачи поважнее и потруднее.
• Мой исходный текст съел кот Мурзик
• Пороки дублирования
• Сила простого текста
• Игры с оболочками
• Отладка
• Генераторы исходных текстов
• Команды прагматиков
• Безжалостное тестирование
• Все эти сочинения
• Посмотрите на свои ежедневные действия. Есть ли у вас повторяющиеся задачи? Набираете ли вы одну и туже последовательность команд раз за разом? Попробуйте написать несколько сценариев оболочки для автоматизации процесса. Всегда ли вы щелкаете мышью по определенной последовательности пиктограмм, повторяя эту операцию снова и снова? Можете ли вы создать макрокоманду, которая будет это делать за вас?
• Какая часть вашей бумажной работы, связанной с проектом, может быть автоматизирована? Учитывая большие расходы на содержание штата программистов [48], определите, какая часть проектного бюджета тратится впустую на административные процедуры. Можете ли вы обосновать временные затраты на создание автоматизированного решения, основываясь на общей экономии затрат, которая достигается при его внедрении?