Фредерик П. Брукс
| Вид материала | Документы |
| Системная отладка Используйте отлаженные компоненты. Создайте больше окружений. Контролируйте изменения. Добавляйте компоненты по одному. Квантуйте изменения. |
- Французский писатель, журналист и критик Фредерик Бегбедер, 1495.8kb.
- Фредерик Коплстон История философии. XX век Номер страницы указан в конце страницы, 2537.19kb.
- Gold Circle Films представляют фильм компании Integrated Films. О фильме история США, 1307.29kb.
- Брукс Кубик "Тренинг Динозавров. Забытые секреты силы и развития тела", 3174.72kb.
- 2. Во всем мире родоначальником научных основ организации производства признан: ◙ Фредерик, 992.99kb.
- Фредерик Бегбедер, 2049.29kb.
- Фредерик Бегбедер. 99 франков, 2045.96kb.
- Фредерик К. Хэтфилд всестороннее руководство по развитию силы , 4595.97kb.
- Фредерик Бегбедер. 99 Франков, 2399.26kb.
- Практикум по гештальттерапии петербург, 5899.47kb.
Системная отладка
Неожиданно трудным этапом создания системы программирования оказывается тестирование системы. Я уже обсуждал некоторые причины как еготрудности, так и непредсказуемости. Можно не сомневаться в двух вещах:системная отладка займет больше времени, чем предполагается, а ее сложностьоправдывает досконально систематичный и плановый подход. Рассмотрим, чтовключает в себя такой подход.12
Используйте отлаженные компоненты. Обычный здравый смысл, если необычная практика, подсказывают, что системную отладку нужно начинать, когдаработает каждая составляющая часть.
Далее общепринятая практика следует двумя путями. Первый подход -"свинти и попробуй". Видимо, он основывается на том, что кроме ошибок вкомпонентах найдутся и ошибки в системе (т.е. в интерфейсах). Чем скореечасти будут соединены вместе, тем скорее всплывут системные ошибки. Легкотакже представить, что, используя компоненты для тестирования друг друга,можно в значительной мере избежать создания окружения для тестирования. Ито, и другое, очевидно, является правдой, но, как показывает опыт, не всейправдой: значительно больше времени сберегается при тестировании системы сиспользованием чистых отлаженных компонентов, чем его тратится на созданиеокружения и доскональной проверки компонентов.
Несколько более тонким является подход "документированной ошибки". Онозначает, что компонент готов к использованию в системной проверке, когдавсе его ошибки найдены, но необязательно уже исправлены. Тогда,теоретически, при системном тестировании возможные эффекты этих ошибокизвестны и могут быть проигнорированы, а сосредоточиться можно на новыхявлениях.
Все это означает принимать желаемое за действительное и происходит отстремления объяснить провал графика работ. Никто не знает всех возможныхпоследствий известных ошибок. Если бы все было просто, системноетестирование не вызывало бы затруднений. Кроме того, исправлениедокументированных ошибок, несомненно, приведет к внесению новых ошибок, исистемный тест окажется испорченным.
Создайте больше окружений. Под "окружением" я понимаю все программы иданные, созданные для целей отладки, но не предназначенные для использованияв конечном продукте. В окружении нет смысла иметь и половины того кода,который входит в продукт.
Один из видов окружения - фиктивный компонент, который может состоятьтолько из интерфейсов и, возможно, каких-нибудь искусственных данных илинебольших контрольных примеров. Например, в систему может входить программасортировки, которая еще не закончена. Связанные с ней компоненты можнотестировать с помощью фиктивной программы, которая просто читает и проверяетформат входных данных и возвращает набор правильно отформатированныхбессмысленных, но упорядоченных данных.
Другой вид - мини-файл. Распространенным видом системной ошибкиявляется неправильное восприятие форматов ленточных и дисковых файлов.Поэтому стоит создать несколько маленьких файлов, содержащих лишь несколькотиповых записей и все описания, указатели и т.п.
Предельный случай мини-файла - фиктивный файл, который фактически несуществует. Язык управляющих заданий OS/360 имеет такое средство, и оноочень полезно для отладки компонентов.
Другой вид окружения - вспомогательные программы. Генераторы данных длятестирования, печать специального анализа, анализаторы таблиц перекрестныхссылок - все это примеры специальных приспособлений, которые можетпотребоваться создать.13
Контролируйте изменения. Жесткий контроль во время тестированияявляется впечатляющим методом отладки аппаратуры, с успехом применимым ксистемам программирования.
Прежде всего, кто-то должен быть ответственным. Он, и только он долженразрешать изменения в компонентах и замену одной версии другой.
Далее, как обсуждалось выше, система должна иметь контролируемыеэкземпляры: один экземпляр с последними версиями, находящийся под замком ииспользуемый для тестирования компонентов; один тестируемый экземпляр сустановленными исправлениями; рабочие экземпляры каждого сотрудника длявнесения исправлений и дополнений в свои компоненты.
В технических моделях System/360 среди обычных желтых проводов можнобыло иногда видеть фиолетовые провода. При обнаружении дефекта делались двевещи. Быстро придумывалось исправление и устанавливалось в системе, чтобыпродолжить отладку. Это изменение делалось фиолетовыми проводами, так чтооно торчало как бельмо на глазу. Изменение регистрировалось в журнале. Темвременем готовился официальный документ о внесении исправлений, которыйзапускался в жернова автоматизированного проектирования. В итоге этовыливалось в измененные чертежи и списки проводов и новую заднюю панель, вкоторой изменения были сделаны на печатной плате или желтыми проводами.Теперь физическая модель и документация соответствовали друг другу, ифиолетовый провод исчезал.
Программированию тоже требуется технология фиолетовых проводов, и оченьтребуется жесткий контроль и глубокое уважение к документу, который вконечном счете, окажется продуктом. Неотъемлемыми составляющими такойтехнологии являются регистрация всех изменений в журнале и заметное отличиев исходном коде между заплатками на скорую руку и продуманными идокументированными исправлениями.
Добавляйте компоненты по одному. Этот рецепт также очевиден, но имчасто пренебрегают из-за оптимизма и лени. Чтобы следовать ему, требуютсяфиктивные программы и разное окружение, а это отнимает время. И в концеконцов, вся эта работа может оказаться лишней! Может быть, ошибок и нет!
Нет! Противьтесь соблазну! Это то, в чем заключается систематичноетестирование системы. Нужно предполагать, что ошибок будет много, ипланировать упорядоченную процедуру избавления от них.
Учтите, что нужно иметь полный набор контрольных примеров для проверкичастично собранных систем после добавления каждого компонента. Прежниепримеры, успешно выполненные на последней частичной сборке, нужноперезапустить на новой, чтобы проверить, не ухудшилась ли система.
Квантуйте изменения. По мере созревания системы время от времени начинают появляться разработчики компонентов, принося свежие версии своих изделий - более быстрые, меньшие по размеру, более полные илипредположительно содержащие меньше ошибок. Замена работающего компонентановой версией требует такой же систематической процедуры тестирования, как идобавление нового компонента, хотя и требует меньше времени, посколькуобычно уже имеются более полные и эффективные контрольные примеры.
Каждая команда, создающая новый компонент, использует новейшую версиюинтегрированной системы в качестве среды для отладки своего компонента.Проделанная работа будет отброшена назад, если эта среда изменится. Конечно,она должна измениться. Но внесение изменений нужно производить квантами.Тогда у каждого пользователя будут промежутки продуктивной стабильности,прерываемые пакетным обновлением среды тестирования. Это оказываетсязначительно менее разрушительным, чем постоянные волнения и дрожь.
Леман и Белади дают свидетельства в пользу того, что квант измененийдолжен быть либо очень большим и редким, либо очень маленьким и частым.14Последняя стратегия, согласно их модели, больше подвержена неустойчивости.Мой опыт это подтверждает: я никогда не рискну использовать ее на практике.
Квантовые изменения хорошо вписываются в технологию фиолетовыхпроводов. Быстрая заплатка держится до следующей регулярной версиикомпонента, которая должна содержать исправление в отлаженном идокументированном виде.