Многие команды разработчиков используют внутренний web-сайт для обмена информацией в ходе выполнения проекта, и мы полагаем, что это прекрасная идея. Но мы не хотим тратить много времени на поддержку web-сайта и не желаем, чтобы информация, содержащаяся на нем, устаревала. Информация, вводящая в заблуждение, хуже, чем отсутствие какой бы то ни было информации вообще.
Документация, извлекаемая из программы, анализа требований, проектных документов и любых чертежей, графиков или диаграмм, должна регулярно публиковаться на web-сайте. Мы предпочитаем публиковать эти документы автоматически – это является частью ночной процедуры сборки или добавочным блоком в процедуре возвращения исходного текста программы в библиотеку.
Однако если это сделано, содержание web-сайта должно генерироваться автоматически из информации, хранящейся в централизованной библиотеке, и публиковаться без вмешательства человека. На самом деле это еще одно применение принципа DRY: информация существует в одной форме – в виде исходного текста и документов в библиотеке. При просмотре с помощью web-браузера они так и выглядят – просто визуальное представление. Вам не придется поддерживать это представление вручную.
Любая информация, сгенерированная в процессе ночной сборки, должна быть доступна на web-сайте разработчиков: результаты самой сборки (они могут быть представлены в виде краткого отчета на одной странице, содержащего предупреждения компилятора, ошибки и текущее состояние), регрессионные тесты, рабочая статистика, программные метрики, а также любые другие результаты статического анализа и т. д.
Некоторые проекты участвуют в административном документообороте, требования которого необходимо соблюдать. Например, рассмотрение проекта или текста программы должно быть спланировано и доведено до конца, документы необходимо утверждать и т. д. Можно использовать автоматизацию и – особенно это касается web-сайта – облегчить бремя, налагаемое бумажной работой.
Предположим, что вы хотели автоматизировать планирование рассмотрения и процедуру утверждения текста программы. В каждый файл с исходным текстом вы могли бы поместить специальный маркер:
/* Status: needs_review */
Простой сценарий должен пройти весь исходный текст до конца и провести поиск всех файлов, находившихся в состоянии needs_review, которое указывало на их готовность к рассмотрению. Затем вы могли бы поместить список этих файлов в виде web-страницы, автоматически послать электронную почту соответствующим адресатам или даже назначить встречу, используя программу календарного планирования.
Вы можете организовать некую форму на web-странице, чтобы рецензенты регистрировали свое утверждение или несогласие. После рассмотрения состояние может быть автоматически изменено на reviewed. Использовать или не использовать сквозной контроль текста программы всеми участниками – это зависит от вас; всю бумажную работу вы можете проделывать автоматически независимо от этого. (В своей статье в журнале САСМ (апрель 1999 г.) Роберт Гласе обобщает результаты исследования, которое, похоже, указывает на то, что критическое рассмотрение текста программы отличается эффективностью, в отличие от рассмотрения в ходе собраний [Gla99a].)
Дети сапожника
Дети сапожника всегда без сапог. Зачастую те, кто занимается разработкой программ, используют наихудшие инструментальные средства для выполнения своей работы.
Но у нас имеются все исходные материалы для того, чтобы создать лучшие инструменты. У нас есть программа cron. У нас есть программа make для платформ Windows и Unix. У нас есть и Perl, а также другие языки сценариев высокого уровня для быстрой разработки заказных инструментальных средств, генераторов web-страниц, исходных тестов программ, тестовых стендов и т. д.
Пусть компьютер делает скучную земную работу – он сделает это лучше, чем мы. У нас есть задачи поважнее и потруднее.
• Мой исходный текст съел кот Мурзик
• Пороки дублирования
• Сила простого текста
• Игры с оболочками
• Отладка