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

 

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

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

/* Status: needs_review */

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

Вы можете организовать некую форму на web-странице, чтобы рецензенты регистрировали свое утверждение или несогласие. После рассмотрения состояние может быть автоматически изменено на reviewed. Использовать или не использовать сквозной контроль текста программы всеми участниками – это зависит от вас; всю бумажную работу вы можете проделывать автоматически независимо от этого. (В своей статье в журнале САСМ (апрель 1999 г.) Роберт Гласе обобщает результаты исследования, которое, похоже, указывает на то, что критическое рассмотрение текста программы отличается эффективностью, в отличие от рассмотрения в ходе собраний [Gla99a].)

 

Дети сапожника

 

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

Но у нас имеются все исходные материалы для того, чтобы создать лучшие инструменты. У нас есть программа cron. У нас есть программа make для платформ Windows и Unix. У нас есть и Perl, а также другие языки сценариев высокого уровня для быстрой разработки заказных инструментальных средств, генераторов web-страниц, исходных тестов программ, тестовых стендов и т. д.

Пусть компьютер делает скучную земную работу – он сделает это лучше, чем мы. У нас есть задачи поважнее и потруднее.

 

Другие разделы, относящиеся к данной теме:

 

• Мой исходный текст съел кот Мурзик

• Пороки дублирования

• Сила простого текста

• Игры с оболочками

• Отладка

• Генераторы исходных текстов

• Команды прагматиков

• Безжалостное тестирование

• Все эти сочинения

 

Вопросы для обсуждения

 

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

• Какая часть вашей бумажной работы, связанной с проектом, может быть автоматизирована? Учитывая большие расходы на содержание штата программистов [48], определите, какая часть проектного бюджета тратится впустую на административные процедуры. Можете ли вы обосновать временные затраты на создание автоматизированного решения, основываясь на общей экономии затрат, которая достигается при его внедрении?

 

 

Безжалостное тестирование

 

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

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

 

 

Подсказка 62: Тестируйте раньше. Тестируйте часто. Тестируйте автоматически

 

 

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

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

Чем раньше обнаружен дефект, тем дешевле обходится его устранение. "Чуть-чуть напишешь, чуть-чуть проверишь" – популярное изречение в мире Smalltalk [49], и мы можем принять эту мантру как нашу личную, создавая одновременно (или даже раньше) с написанием рабочей программы программу ее тестирования.

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

Кроме того, осознание, что вы прошли тест, дает вам большую степень уверенности в том, что этот фрагмент программы "готов".

 

 

Подсказка 63: Программа не считается написанной, пока не пройдет тестирование

 

 

Тот факт, что вы закончили работу с фрагментом программы, вовсе не означает, что можно идти к шефу или заказчику, чтобы сообщить ему о «готовности». Фрагмент не готов. Прежде всего, программа в реальности никогда не бывает готовой. И, что более важно, пока она не пройдет все имеющиеся тесты, вы не можете утверждать, что она может использоваться кем бы то ни было.

Необходимо рассмотреть три основных аспекта тестирования в масштабе всего проекта: что тестировать, как тестировать и когда тестировать.

 

Что тестировать

 

Существует несколько видов процедур тестирования программного обеспечения, которые вам приходится выполнять:

• Модульное тестирование

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

• Подтверждение правильности и верификация

• Тестирование в условиях нехватки ресурсов, ошибки и их исправление

• Тестирование производительности

• Тестирование удобства использования

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

 

Модульное тестирование

 

Модульный тест представляет собой программу, занимающуюся тестированием некоего модуля. Эта тема освещена в разделе "Программа, которую легко тестировать". Модульное тестирование является основой для всех других видов тестирования, которые обсуждаются в данном разделе. Если части не работают по отдельности, то скорее всего они не будут хорошо работать и вместе. Все используемые модули обязаны пройти собственное модульное тестирование перед тем как продолжать работу.

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

 

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

 

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

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