Программист-прагматик. Путь от подмастерья к мастеру
Шрифт:
• Искусственные тесты (такие, как одна-единственная черта, проведенная «кистью» снизу вверх) недостаточны для испытания приложения. Необходимо осуществлять тестирование обоих граничных условий и реалистических шаблонов действия конечного пользователя. Это нужно делать систематически (см. "Безжалостное тестирование").
Стратегии отладки
Если вы уверены, что знаете, в чем дело, пора выяснить, как сама программа относится к происходящему.
Нет, наши ошибки на самом деле не размножаются (хотя некоторые
Начать устранение ошибки лучше всего с придания ей свойства воспроизводимости. В конце концов, если вы не можете воспроизвести ее, то как узнать, что она вообще устранена?
Но нам нужно нечто большее, чем ошибка, которая воспроизводится с помощью некоторой последовательности операций; нам нужна ошибка, которую можно воспроизвести при помощи одной-единственной команды. Процедура устранения ошибки многократно усложняется, когда вам приходится выполнять 15 операций, чтобы добраться до места, где эта ошибка выявляется. В ряде случаев вы можете интуитивно понять, как можно устранить ошибку, заставив себя абстрагироваться от тех обстоятельств ее проявления.
Другие идеи, касающиеся вышеприведенного, представлены в разделе "Вездесущая автоматизация".
Пристальный взгляд на данные, с которыми работает программа, во многих случаях является лучшим способом увидеть то, что же она делает (или собирается делать). Простейшим примером этого является прямолинейный подход типа "переменная = значение", который может быть реализован в виде печатного текста или в виде полей диалогового окна (списка) графического интерфейса.
Но вы можете проникнуть в суть данных намного глубже, используя отладчик, который позволяет визуализировать данные и все существующие отношения между ними. Существуют отладчики, которые могут представить ваши данные с высоты полета над трехмерным ландшафтом виртуальной реальности или в виде трехмерного временного графика сигналов, или же просто в виде обычных блок-схем, как показано на рисунке 3.2. По мере того как вы перемещаетесь шаг за шагом по вашей программе, рисунки, подобные этим, могут оказаться ценнее, чем тысячи слов, если ошибка, за которой вы охотились, неожиданно выпрыгивает на вас, как зверь на ловца.
Даже если отладчик имеет ограниченную поддержку визуализации данных, вы все равно можете проводить визуализацию сами – либо вручную, с карандашом и бумагой, либо с помощью внешних программ построения графиков.
В отладчике DDD имеются некоторые средства визуализации, которые распространяются бесплатно (см. [URL 19]). Интересно заметить, что отладчик DDD работает со многими языками, включая Ada, С, С++, Fortran, Java, Modula, Pascal, Perl и Python (явно ортогональная конструкция).
Рис. 3.2. Пример отладочной схемы циркулярного связанного списка. Стрелки указывают на узлы.
Отладчики обычно сосредоточены на состоянии программ в данный момент. В ряде случаев вам необходимо нечто большее – отследить состояние программы или структуры данных через какое-то время. Если посмотреть
Операторы трассировки представляют собой небольшие диагностические сообщения, которые выводятся на экран или в файл и говорят о том, что "это здесь" и "х = 2". Это примитивная методика, сравнимая с отладчиками в стиле ИСР, но она особенно эффективна при диагностировании некоторых классов ошибок, с которыми отладчики справиться не могут. Трассировка имеет большое значение в любой системе, где время само по себе является фактором: в одновременных процессах, системах реального времени и приложениях, основанных на событиях.
Вы можете использовать операторы трассировки для того, чтобы "вбуравиться" в текст. То есть вы можете добавлять элементы трассировки по мере продвижения вниз по дереву обращений.
Трассировочные сообщения должны быть представлены в регулярном, согласованном формате; возможно, вам захочется провести их синтаксический анализ в автоматическом режиме. Например, если вам необходимо отследить утечку ресурсов (несбалансированные операции открытия и закрытия файлов), вы можете трассировать каждый из операторов open и close в файле журнала. Обрабатывая файл журнала с помощью программы на языке Perl, вы легко обнаружите, где встречался оператор-нарушитель open.
Иногда вы исследуете переменную, ожидая увидеть небольшое целое значение, а вместо этого получаете нечто вроде 0x6e696614d. Перед тем как засучив рукава всерьез приняться за отладку, стоит посмотреть на память вокруг искаженного значения. Часто это дает вам ключ к пониманию. В данном случае, изучение окружающей памяти в символьном виде дает следующую картину:
Похоже, что кто-то указал адрес поверх счетчика цикла. Теперь, мы знаем где искать.
Очень простая, но весьма полезная методика поиска причины проблемы, состоит в том, чтобы разъяснить ее кому-либо. Ваш собеседник должен заглядывать через ваше плечо на экран монитора и время от времени утвердительно кивать головой (подобно резиновому утенку, ныряющему и выныривающему в ванне). Ему не нужно говорить ни слова; простое, последовательное объяснение того, что же должна делать ваша программа, часто приводит к тому, что проблема выпрыгивает из монитора и объявляет во всеуслышанье: "А вот и я!" [22] .
22
Почему "резиновый утенок"? Один из авторов книги, Дэйв Хант, учился в лондонском Империал колледже и много работал совместно с аспирантом, которого звали Грег Паг и которого Д. Хант считает одним из лучших известных ему разработчиков. На протяжении нескольких месяцев Грег носил при себе крохотного желтого резинового утенка, которого он ставил на край монитора во время работы. Прошло некоторое время, пока Дэйв не отважился спросить…