Английское слово bug (ошибка) используется для описания "объекта, вызывающего ужас" уже начиная с XIV в. Контр-адмирал д-р Грэйс Хоппер (создатель языка COBOL) оказался первым, кто наблюдал компьютерного «жучка», буквально – моли, попавшей в одно из электромеханических реле, из которых состояли первые вычислительные системы. Когда техника попросили объяснить, почему машина ведет себя не так, как надо, он сообщил, что в системе "завелся жучок", и в соответствии со своими должностными обязанностями приклеил его клейкой лентой вместе с крылышками и всем остальным в рабочий журнал.
      К сожалению, мы до сих пор встречаемся с «жучками» в системе, хотя и не из рода перепончатокрылых. Но значение этого слова, принятое в XIV в. – привидение – возможно более применимо сейчас, нежели тогда. Изъяны в программном обеспечении проявляют себя по-разному – от превратно истолкованных требований до ошибок в написании исходных текстов. К сожалению, возможности современных компьютерных систем все еще ограничены исполнением только того, что мы им прикажем, а не обязательно того, что мы хотим, чтобы они сделали.
      Никто не создает совершенное программное обеспечение, так что примите как данность тот факт, что отладка будет занимать большую часть вашего рабочего дня. Рассмотрим некоторые аспекты, вовлеченные в процесс отладки, и некоторые универсальные стратегии поиска неуловимых ошибок.

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

      Подсказка 24: Занимайтесь устранением проблемы, а не обвинениями

 
      На самом деле, не важно, кто виноват в ошибке – вы или кто-то другой. Это все равно остается вашей проблемой.

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

      Подсказка 25: Не паникуйте

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

      Перед тем как взглянуть на ошибку, убедитесь, что вы работаете над программой, которая прошла стадию компиляции чисто – без предупреждений. Обычно мы устанавливаем уровни предупреждения компиляторов максимально высокими. Нет смысла тратить время в попытках найти проблему, которую не смог найти и компилятор! Необходимо сосредоточиться на более сложных насущных проблемах.
      Пытаясь решить любую проблему, нужно собрать все относящиеся к делу данные. К сожалению, отчеты об ошибках не являются точной наукой. Легко впасть в заблуждение из-за совпадений, а вы не можете позволить себе тратить время на исследование причин совпадений. Необходимо быть точным в ваших наблюдениях изначально.
      Точность отчетов об ошибках снижается еще больше, когда их просматривает третья сторона, в реальности может оказаться, что вам придется наблюдать за действиями пользователя, который сообщил об ошибке, чтобы добиться достаточного уровня детализации.
      Однажды один из авторов книги (Энди Хант) работал над большим графическим приложением. Дело уже шло к выпуску готовой версии, когда тестировщики сообщили о том, что приложение «падало» всякий раз, когда они проводили черту при помощи конкретной кисти. Программист начал оспаривать это утверждение, говоря о том, что все в порядке: он сам пытался выполнять аналогичную прорисовку, и все работало превосходно. Обмен любезностями продолжался в течение нескольких дней, когда напряженность вдруг резко возросла.
      В конце концов все собрались в одной комнате. Тестировщик выбрал нужный инструмент (кисть) и провел черту, из ВЕРХНЕГО ПРАВОГО угла к НИЖНЕМУ ЛЕВОМУ. Приложение «упало»! Программист тихонько охнул, а затем виновато проблеял, что при тестировании он проводил черту только из НИЖНЕГО ЛЕВОГО угла к ВЕРХНЕМУ ПРАВОМУ, и при этом ошибка никак не выявлялась.
      В этой истории есть два момента, заслуживающих внимания:
      • Может возникнуть необходимость в опросе пользователя, который сообщил о присутствии ошибки, для того чтобы собрать больше данных, чем было дано изначально.
      • Искусственные тесты (такие, как одна-единственная черта, проведенная «кистью» снизу вверх) недостаточны для испытания приложения. Необходимо осуществлять тестирование обоих граничных условий и реалистических шаблонов действия конечного пользователя. Это нужно делать систематически (см. "Безжалостное тестирование").

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

Воспроизведение ошибок

      Нет, наши ошибки на самом деле не размножаются (хотя некоторые из них возможно достаточно стары, чтобы делать это уже на законных основаниях). Мы говорим о другом способе размножения.
      Начать устранение ошибки лучше всего с придания ей свойства воспроизводимости. В конце концов, если вы не можете воспроизвести ее, то как узнать, что она вообще устранена?
      Но нам нужно нечто большее, чем ошибка, которая воспроизводится с помощью некоторой последовательности операций; нам нужна ошибка, которую можно воспроизвести при помощи одной-единственной команды. Процедура устранения ошибки многократно усложняется, когда вам приходится выполнять 15 операций, чтобы добраться до места, где эта ошибка выявляется. В ряде случаев вы можете интуитивно понять, как можно устранить ошибку, заставив себя абстрагироваться от тех обстоятельств ее проявления.
      Другие идеи, касающиеся вышеприведенного, представлены в разделе "Вездесущая автоматизация".

Сделайте ваши данные наглядными

      Пристальный взгляд на данные, с которыми работает программа, во многих случаях является лучшим способом увидеть то, что же она делает (или собирается делать). Простейшим примером этого является прямолинейный подход типа "переменная = значение", который может быть реализован в виде печатного текста или в виде полей диалогового окна (списка) графического интерфейса.
      Но вы можете проникнуть в суть данных намного глубже, используя отладчик, который позволяет визуализировать данные и все существующие отношения между ними. Существуют отладчики, которые могут представить ваши данные с высоты полета над трехмерным ландшафтом виртуальной реальности или в виде трехмерного временного графика сигналов, или же просто в виде обычных блок-схем, как показано на рисунке 3.2. По мере того как вы перемещаетесь шаг за шагом по вашей программе, рисунки, подобные этим, могут оказаться ценнее, чем тысячи слов, если ошибка, за которой вы охотились, неожиданно выпрыгивает на вас, как зверь на ловца.
      Даже если отладчик имеет ограниченную поддержку визуализации данных, вы все равно можете проводить визуализацию сами – либо вручную, с карандашом и бумагой, либо с помощью внешних программ построения графиков.
      В отладчике DDD имеются некоторые средства визуализации, которые распространяются бесплатно (см. [URL 19]). Интересно заметить, что отладчик DDD работает со многими языками, включая Ada, С, С++, Fortran, Java, Modula, Pascal, Perl и Python (явно ортогональная конструкция).
 
      Рис. 3.2. Пример отладочной схемы циркулярного связанного списка. Стрелки указывают на узлы.
 

Трассировка

      Отладчики обычно сосредоточены на состоянии программ в данный момент. В ряде случаев вам необходимо нечто большее – отследить состояние программы или структуры данных через какое-то время. Если посмотреть на трассировку стека, то можно лишь сделать вывод, как попасть в эту точку напрямую. Это не дает информации о том, что вы делали до этой последовательности обращений, что особенно важно для систем, основанных на событиях.
      Операторы трассировки представляют собой небольшие диагностические сообщения, которые выводятся на экран или в файл и говорят о том, что "это здесь" и "х = 2". Это примитивная методика, сравнимая с отладчиками в стиле ИСР, но она особенно эффективна при диагностировании некоторых классов ошибок, с которыми отладчики справиться не могут. Трассировка имеет большое значение в любой системе, где время само по себе является фактором: в одновременных процессах, системах реального времени и приложениях, основанных на событиях.
      Вы можете использовать операторы трассировки для того, чтобы "вбуравиться" в текст. То есть вы можете добавлять элементы трассировки по мере продвижения вниз по дереву обращений.
      Трассировочные сообщения должны быть представлены в регулярном, согласованном формате; возможно, вам захочется провести их синтаксический анализ в автоматическом режиме. Например, если вам необходимо отследить утечку ресурсов (несбалансированные операции открытия и закрытия файлов), вы можете трассировать каждый из операторов open и close в файле журнала. Обрабатывая файл журнала с помощью программы на языке Perl, вы легко обнаружите, где встречался оператор-нарушитель open.

Искаженные переменные! Проверьте их окружение

      Иногда вы исследуете переменную, ожидая увидеть небольшое целое значение, а вместо этого получаете нечто вроде 0x6e696614d. Перед тем как засучив рукава всерьез приняться за отладку, стоит посмотреть на память вокруг искаженного значения. Часто это дает вам ключ к пониманию. В данном случае, изучение окружающей памяти в символьном виде дает следующую картину:
      Похоже, что кто-то указал адрес поверх счетчика цикла. Теперь, мы знаем где искать.

Рассказ о резиновом утенке

      Очень простая, но весьма полезная методика поиска причины проблемы, состоит в том, чтобы разъяснить ее кому-либо. Ваш собеседник должен заглядывать через ваше плечо на экран монитора и время от времени утвердительно кивать головой (подобно резиновому утенку, ныряющему и выныривающему в ванне). Ему не нужно говорить ни слова; простое, последовательное объяснение того, что же должна делать ваша программа, часто приводит к тому, что проблема выпрыгивает из монитора и объявляет во всеуслышанье: "А вот и я!" .
      Звучит просто, но разъясняя проблему вашему собеседнику, вы должны явно заявить о тех вещах, которые считаете само собой разумеющимися при просмотре текста вашей программы. Поскольку вам приходится озвучивать некоторые из этих положений, вы можете по-новому взглянуть на суть данной проблемы – неожиданно для самого себя.

Процесс исключения

      В большинстве проектов отлаживаемая вами программа может представлять собой смесь прикладных программ, написанных лично вами и другими сотрудниками вашей проектной команды, а также программные продукты, созданные независимыми производителями (база данных, обеспечение связи, графические библиотеки, специализированные протоколы связи или алгоритмы, и т. д.) и платформенное окружение (операционная система, системные библиотеки и компиляторы).
      Вероятно, ошибка кроется в операционной системе, компиляторе или продукте независимого производителя – но это не должно быть первой мыслью, приходящей вам на ум. Скорее всего, ошибка существует в тексте разрабатываемого приложения. Обычно выгоднее полагать, что прикладная программа некорректно обращается к библиотеке, нежели то, что нарушена сама библиотека. Даже если проблема заключается в продукте независимого производителя, то перед тем, как представлять отчет об ошибках, вам в любом случае надлежит исключить ошибки в вашей собственной программе.
      Однажды мы работали над проектом, и старший инженер был уверен, что в системе Solaris имелось нарушение системного вызова select. Никакие убеждения или логические построения не могли изменить сложившегося у него мнения (тот факт, что все другие сетевые приложения работали прекрасно, не принимался во внимание). Неделями он составлял программы обхода этого вызова, которые, по какой-то странной причине, не способствовали решению проблемы. И когда в конце концов он был вынужден сесть за стол и прочесть документацию по вызову select, он обнаружил, в чем заключалась проблема, и исправил ее за несколько минут. Теперь мы используем выражение "вызов select нарушен" как деликатное напоминание, в тех случаях, когда один из нас начинает обвинять систему в наличии ошибки, которая, скорее всего, является его собственной.
 

      Подсказка 26: Ищите ошибки вне пределов операционной системы

 
      Помните: увидев следы копыт, думайте о лошадях, а не о зебрах. Скорее всего, операционная система не нарушена. Да и база данных находится в прекрасном состоянии.
      Если вы "внесли всего одно изменение", и система перестала работать, то, скорее всего, именно оно, прямо или косвенно, несет ответственность за случившееся, каким бы притянутым за уши ни казалось это утверждение. Иногда то, что изменяется, находится вне вашего управления: новые версии операционной системы, компилятора, базы данных или программы независимых производителей могут вызывать проблемы и с изначально корректной программой. В ней могут обнаружиться новые ошибки. Ошибки, которые были устранены с помощью программы обхода, преодолевают действие этой программы. Если изменяются API, то изменяются и функциональные возможности; короче говоря, это уже новая история, и вам надлежит провести повторное тестирование системы в новых сложившихся условиях. Так что не спускайте глаз с графика выполнения проекта, если собираетесь провести модернизацию; может быть, придется подождать до выпуска новой версии.
      Однако если вы не знаете, с чего начать, то всегда можете положиться на старый добрый двоичный поиск. Обратите внимание, не проявляются ли симптомы в одной из двух точек в тексте программы, находящихся далеко друг от друга. Затем посмотрите на точку, расположенную между ними. При наличии проблемы, ошибка «сидит» между начальной и срединной точкой; в противном случае она «сидит» между срединной и конечной точками. Продолжая действовать в этом ключе, вы сужаете область поиска, пока не выявите ошибку.

      Если ошибка вызвала у вас удивление (до того, что вы еле слышно бормочете "Этого не может быть"), стоит провести переоценку истин, дорогих вашему сердцу. А все ли граничные условия вы протестировали в подпрограмме связанного списка – той, которую вы считали непробиваемой и которая, по всей вероятности, не могла стать причиной этой ошибки? А другой фрагмент текста программы, который вы использовали в течение нескольких лет, – не мог ли он все еще таить в себе ошибку?
      Конечно, мог. То удивление, которое вы испытываете, когда что-то идет не так как надо, прямо пропорционально уровню доверия и веры в правильность прогоняемой программы. Поэтому, столкнувшись с «удивительным» отказом в работе программы, вы должны осознать, что одно или более ваших предположений неверны. Не приукрашивайте подпрограмму или фрагмент текста программы, вызвавший ошибку, только потому, что «знаете», что он работает нормально. Вначале докажите это. Докажите это в реальном контексте, с реальными данными, с реальными граничными условиями.
 

      Подсказка 27: Не предполагайте – доказывайте

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

      • Является ли проблема прямым результатом фундаментальной ошибки или просто ее признаком?
      • Ошибка действительно «сидит» в компиляторе? В операционной системе? Или в вашей собственной программе?
      • Если бы вам пришлось подробно объяснить вашему коллеге, в чем состоит проблема, что бы вы ему сказали?
      • Если подозрительная программа проходит модульное тестирование, то является ли оно достаточно полным? Что произойдет, если вы прогоняете модульный тест с реальными данными?
      • Существуют ли условия, вызвавшие данную ошибку, где-либо еще в системе?

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

      • Программирование на основе утверждений
      • Программирование в расчете на совпадение
      • Вездесущая автоматизация
      • Безжалостное тестирование

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

      • Отладка сама по себе является вопросом.