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

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

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

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

В отладчике DDD имеются некоторые средства визуализации, которые распространяются бесплатно (см. [URL 19]). Интересно заметить, что отладчик DDD работает со многими языками, включая Ada, С, С++, Fortran, Java, Modula, Pascal, Perl и Python (явно ортогональная конструкция).

Рис. 3.2. Пример отладочной схемы циркулярного связанного списка. Стрелки указывают на узлы.

Трассировка

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

Операторы трассировки представляют собой небольшие диагностические сообщения, которые выводятся на экран или в файл и говорят о том, что "это здесь" и "х = 2". Это примитивная методика, сравнимая с отладчиками в стиле ИСР, но она особенно эффективна при диагностировании некоторых классов ошибок, с которыми отладчики справиться не могут. Трассировка имеет большое значение в любой системе, где время само по себе является фактором: в одновременных процессах, системах реального времени и приложениях, основанных на событиях.

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

Трассировочные сообщения должны быть представлены в регулярном, согласованном формате; возможно, вам захочется провести их синтаксический анализ в автоматическом режиме. Например, если вам необходимо отследить утечку ресурсов (несбалансированные операции открытия и закрытия файлов), вы можете трассировать каждый из операторов open и close в файле журнала. Обрабатывая файл журнала с помощью программы на языке Perl, вы легко обнаружите, где встречался оператор-нарушитель open.

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

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

Похоже, что кто-то указал адрес поверх счетчика цикла. Теперь, мы знаем где искать.

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

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

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

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

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

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

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

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

Помните: увидев следы копыт, думайте о лошадях, а не о зебрах. Скорее всего, операционная система не нарушена. Да и база данных находится в прекрасном состоянии.

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

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

Элемент удивления

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

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

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

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

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

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

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

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

Проделайте все это, и наверняка в следующий раз вы будете избавлены от подобных сюрпризов.

Контрольные вопросы при отладке

• Является ли проблема прямым результатом фундаментальной ошибки или просто ее признаком?

• Ошибка действительно «сидит» в компиляторе? В операционной системе? Или в вашей собственной программе?

• Если бы вам пришлось подробно объяснить вашему коллеге, в чем состоит проблема, что бы вы ему сказали?

• Если подозрительная программа проходит модульное тестирование, то является ли оно достаточно полным? Что произойдет, если вы прогоняете модульный тест с реальными данными?

• Существуют ли условия, вызвавшие данную ошибку, где-либо еще в системе?

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

• Программирование на основе утверждений

• Программирование в расчете на совпадение

• Вездесущая автоматизация

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

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

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

Обработка текста

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

Языки, предназначенные для обработки текста, играют в программировании ту же роль, что станки [23] в столярном деле. Они издают шум, неуклюжи и представляют собой грубую силу. Если при работе с ними вы совершаете ошибку, то разрушенными могут оказаться целые фрагменты. Некоторые клятвенно уверяют, что этим средствам нет места в инструментарии. Но в хороших руках и станки, и языки обработки текста могут быть невероятно мощными и гибкими. Вы можете быстро придать форму материалу, делать стыки и вырезать по дереву. При надлежащем использовании эти инструменты обладают удивительной тонкостью и ловкостью. Но для овладения ими требуется время.

Число хороших языков обработки текста постоянно увеличивается. Разработчики программ для Unix часто любят использовать мощь их командных оболочек, усиленных инструментальными средствами типа awk и sed. Тем, кто предпочитает более структурированные средства, больше по душе объектно-ориентированный характер языка Python [URL 9]. Выбор некоторых падает на Tel [URL 23]. Случается, и мы предпочитаем язык Perl [URL 8] для написания коротких сценариев.

Эти языки являются важными узаконивающими технологиями. Используя их, вы можете быстро решить все проблемы с утилитами и создать прототипы идей – при работе с обычными языками на это потребовалось бы раз в пять-десять больше времени. И этот умножающий коэффициент кардинально важен для экспериментов, которые мы проводим. Потратить 30 минут на воплощение сумасшедшей идеи намного лучше, чем потратить на то же пять часов. Потратить один день на автоматизацию важных составляющих проекта – нормально, потратить неделю – может быть, и нет. В книге "The Practice of Programming" [KP99], Керниган и Пайк реализовали одну и ту же программу на пяти различных языках. Самой короткой оказалась версия на языке Perl (17 строк по сравнению со 150 строками на языке С). Работая с языком Perl, вы можете обрабатывать текст, взаимодействовать с другими программами, передавать данные по сетям, управлять web-страницами, производить арифметические действия с произвольной точностью и писать программы, которые выглядят наподобие клятвы Снупи.

Подсказка 28: Изучите язык обработки текстов

Чтобы продемонстрировать широту области применения языков обработки текста, в качестве примера мы приводим некоторые приложения, разработанные нами на протяжении последних нескольких лет:

• Сопровождение схемы базы данных. Набор сценариев на языке Perl обрабатывал файл с простым текстом, содержащий определение схемы базы данных и генерировал из него:

– Инструкции SQL для создания БД

– Плоские файлы данных для заполнения словаря данных

– Библиотеки программ на языке С для доступа к БД

– Сценарии для проверки целостности БД

– Web-страницы, содержащие описания и блок-схемы БД

– XML версию схемы

• Доступ к свойству Java. Хорошим тоном в объектно-ориентированном программировании является ограничение доступа к свойствам объекта, что вынуждает внешние классы получать и устанавливать их через методы. Однако в общем случае, когда свойство представлено внутри класса при помощи простого поля, создание метода get и set для каждой переменной представляет собой утомительную механическую процедуру. У нас имеется сценарий Perl, который изменяет исходные файлы и вставляет правильные определения метода для всех переменных, помеченных соответствующим образом.

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

• Написание книг. Мы придаем важность тому факту, что любая программа, представленная в книге, вначале должна быть протестирована. Большинство программ, приведенных в этой книге, были протестированы. Однако, используя принцип DRY (см. "Пороки дублирования"), мы не хотели копировать и вставлять строки текста из протестированных программ в книгу. Это означало бы, что текст дублируется, поэтому велика вероятность, что мы забудем обновить пример, когда соответствующая программа изменится. В некоторых примерах нам также не хотелось утомлять вас наличием «скелета» программы, необходимым для компиляции и прогона нашего примера. Мы обратились к языку Perl. При форматировании книги вызывался относительно простой сценарий – он извлекал именованный сегмент исходного файла, выделял синтаксические конструкции и преобразовывал результат в язык, который мы используем для подготовки типографского макета книг.

• Интерфейс между языками С и Object Pascal. У заказчика имеется команда разработчиков, пишущих программы на языке Object Pascal, реализованном на персональных компьютерах. Требуется осуществить сопряжение их программы с телом программы, написанной на языке С. Был разработан короткий сценарий на языке Perl, который проводил синтаксический анализ файлов заголовков С, выделяя определения всех экспортированных функций и используемых ими структур данных. Затем сгенерированы модули Object Pascal с записями Pascal для всех структур С и произведен импорт определений процедур для всех функций С. Этот процесс генерирования стал частью сборки, так что при любых изменениях заголовка С происходит автоматическое конструирование нового модуля Object Pascal.

• Генерирование интернет-документации. Многие команды разработчиков публикуют свою документацию на внутренних интернет-сайтах. Авторами написано много программ на языке Perl, которые анализируют схемы баз данных, исходные файлы на С и С++, сборочные файлы и другие исходные тексты проекта для производства требуемой HTML-документации. Авторы также использовали язык Perl для верстки документов со стандартными верхними и нижними колонтитулами и передачи их на интернет-сайт.

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

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

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

Упражнения

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

name

state_a

state_b

: :

Создайте файл name.h, содержащий следующие строки:

extern const char * NAME_names[]

extern const char * NAME_names[]

typedef enum {

state_a,

state_b,

: :

} NAME;

а также файл name.с, содержащий следующие строки:

const char * NAME_names[] = {

"statea",

"state_b"

: :

};

12. Дописав эту книгу до середины, авторы обнаружили, что не поместили директиву use strict во многие примеры на языке Perl. Напишите сценарий, который просматривает все файлы типа *.pl в некотором каталоге и добавляет директиву use strict в конец начального блока комментариев ко всем файлам, где это не было сделано ранее. Не забудьте сохранить резервную копию всех файлов, в которые внесены изменения. (Ответ см. в Приложении В.)

Генераторы текстов программ

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

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

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

Подсказка 29: Пишите текст программы, которая пишет текст программы

Существует два основных типа генераторов текста:

1. Пассивные генераторы текста запускаются один раз для достижения результата. Начиная с этого момента результат становится независимым – он отделяется от генератора текста. Мастера, обсуждаемые в разделе "Злые волшебники", вместе с некоторыми средствами CASE являются примерами пассивных генераторов текста.

2. Активные генераторы текста используются всякий раз, когда возникает необходимость в результатах их работы. Этот результат создается по принципу "выбросить и забыть" – он всегда может быть воспроизведен с помощью генератора текста. Зачастую активные генераторы считывают некоторую форму сценария или управляющего файла для получения конечного результата.

Пассивные генераторы

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

• Создание новых исходных файлов. Пассивный генератор текста может создавать шаблоны, директивы управления исходным текстом, сведения об авторских правах и стандартные блоки комментариев для каждого нового файла в некотором проекте. Мы настроили наши редакторы на выполнение этого действия всякий раз при создании нового файла: при редактировании новой программы на языке Java в новом буфере редактора автоматически окажутся уже заполненные блок комментариев, директива пакета и описание структурного класса.

• Осуществление двоичных преобразований в языках программирования. Мы начали писать эту книгу, используя систему troff, но после пятнадцатого раздела перешли на LaTeX. Мы написали генератор текста, который считывал исходный текст из troff и преобразовывали его в формат LATЈX. Точность составила 90 %; остальное мы делали вручную. Это является интересной особенностью пассивных генераторов текста: они не должны отличаться абсолютной точностью. Вы выбираете, какое усилие необходимо вложить в генератор, в сравнении с энергией, которую вы тратите на устранение ошибок в выходной информации.

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

Активные генераторы текста

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

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

Допустим, вы разрабатываете приложение БД. В этом случае вы имеете дело с двумя средами – базой данных и языком программирования, который используется для доступа к БД. У вас есть схема, и вам необходимо определить низкоуровневые конструкции, отражающие компоновку определенных таблиц БД. Вы могли бы просто запрограммировать их напрямую, но при этом нарушается принцип DRY: знание схемы было бы выражено дважды. Если схема меняется, вам необходимо помнить и о соответствующем изменении текста программы. Если из таблицы удаляется столбец, а база текста программы не меняется, то может статься, что ошибка не проявится даже при компиляции. Первый раз вы узнаете об этом во время тестирования, когда начнутся сбои (или же от пользователя).

Рис. 3.3. Активный генератор создает текст программы из схемы базы данных

Альтернативой этому является использование активного генератора текста – берется схема и используется для генерации исходного текста конструкций, как показано на рисунке 3.3. Теперь при любом изменении схемы будет происходить и автоматическое изменение программы, используемой для доступа к ней. При удалении столбца исчезает и соответствующее поле в конструкции, и любая высокоуровневая программа, использующая этот столбец, не пройдет компиляцию. Ошибку удалось заметить во время компиляции, а не в процессе сборки. Конечно, эта схема работает только в том случае, если вы сделаете генерацию текста частью самого процесса сборки [24].

Другим примером слияния сред с помощью генераторов текста является случай, когда в одном и том же приложении использованы различные языки программирования. Для того чтобы общаться, каждой программной базе необходима некоторая общая информация – например, структуры данных, форматы сообщений и имена полей. Вместо того, чтобы дублировать эту информацию, используйте генератор текста. В ряде случаев можно проводить синтаксический анализ информации из исходных файлов на одном языке и использовать ее для генерации текста на другом. Хотя зачастую легче выразить ее более простым, независимым от языка представлением и сгенерировать программу для обоих языков, как показано на рисунке 3.4. Также можно посмотреть ответ к упражнению 13 (см. Приложение В) в качестве примера того, как отделить синтаксический анализ представления плоского файла от генерации текста.