Фредерик Брукс - Мифический человеко-месяц или как создаются программные системы

Предельный случай мини-файла — фиктивный файл, который фактически не существует. Язык управляющих заданий OS/360 имеет такое средство, и оно очень полезно для отладки компонентов.

Другой вид окружения — вспомогательные программы. Генераторы данных для тестирования, печать специального анализа, анализаторы таблиц перекрестных ссылок — все это примеры специальных приспособлений, которые может потребоваться создать. [13]

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

Прежде всего, кто-то должен быть ответственным. Он, и только он должен разрешать изменения в компонентах и замену одной версии другой.

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

В технических моделях System/360 среди обычных желтых проводов можно было иногда видеть фиолетовые провода. При обнаружении дефекта делались две вещи. Быстро придумывалось исправление и устанавливалось в системе, чтобы продолжить отладку. Это изменение делалось фиолетовыми проводами, так что оно торчало как бельмо на глазу. Изменение регистрировалось в журнале. Тем временем готовился официальный документ о внесении исправлений, который запускался в жернова автоматизированного проектирования. В итоге это выливалось в измененные чертежи и списки проводов и новую заднюю панель, в которой изменения были сделаны на печатной плате или желтыми проводами. Теперь физическая модель и документация соответствовали друг другу, и фиолетовый провод исчезал.

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

Добавляйте компоненты по одному. Этот рецепт также очевиден, но им часто пренебрегают из-за оптимизма и лени. Чтобы следовать ему, требуются фиктивные программы и разное окружение, а это отнимает время. И в конце концов, вся эта работа может оказаться лишней! Может быть, ошибок и нет!

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

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

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

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

Леман и Белади дают свидетельства в пользу того, что квант изменений должен быть либо очень большим и редким, либо очень маленьким и частым. [14] Последняя стратегия, согласно их модели, больше подвержена неустойчивости. Мой опыт это подтверждает: я никогда не рискну использовать ее на практике.

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

Как оказывается, что проект запаздывает на год? … Сначала запаздывает на один день.

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

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

Вехи или помехи?

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

Для выбора всех вех есть только одно пригодное правило. Вехами должны служить конкретные особые события, которые можно идентифицировать с полной определенностью. В качестве отрицательных примеров отметим, что написание программы «закончено на 90 процентов» в течение половины всего времени кодирования. Отладка «закончена на 99 процентов» почти всегда. «Планирование завершено» — событие, которое можно объявить почти произвольно. [1]

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