Читать онлайн «Искусство программирования для Unix». Страница 119

15.6. Отладка времени выполнения

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

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

Однако одного только проектирования прозрачных конструкций недостаточно. При отладке программы во время выполнения чрезвычайно полезно иметь возможность изучать состояние выполняемой программы, устанавливать точки останова и контролируемым способом выполнять блоки программы вплоть до уровня одного оператора. В операционной системе Unix имеется давняя традиция поддержки программ, способствующих решению данных проблем. В состав Unix-систем с открытыми исходными кодами входит одно мощное средство, gdb (еще один FSF-проект), которое поддерживает отладку кода, написанного на С и С++.

Языки Perl, Python, Java и Emacs Lisp поддерживают стандартные пакеты или программы (которые включаются в состав их базовых дистрибутивов), позволяющие устанавливать контрольные точки, управлять выполнением и осуществлять общие операции отладки во время выполнения. Tcl, разработанный как небольшой язык для небольших проектов, не имеет такого средства (хотя он имеет средство трассировки, которое можно использовать для наблюдения за переменными во время выполнения).

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

Общее правило: 90% времени выполнения программы тратится на 10% ее кода. Профайлеры представляют собой инструменты, способствующие идентификации этих 10% "горячих точек", которые ограничивают скорость программы, а значит, профайлеры — это хороший способ повышения скорости.

Однако в традиции Unix профайлерам отводится гораздо более важная функция. Они позволяют разработчику не оптимизировать оставшиеся 90%. И это не только сокращает объем работ. Действительно ценный эффект заключается в том, что программист, который не оптимизирует 90% кода, сдерживает глобальную сложность и сокращает количество ошибок.

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

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

Профайлеры для компилируемых языков зависят от измерения параметров объектного кода, поэтому они еще больше зависят от платформы, чем компиляторы. С другой стороны, профайлер компилируемого языка не заботится об исходном языке измеряемой им программы. В Unix один профайлер gprof(1) обрабатывает С, С++ и все остальные компилируемые языки.

Языки Perl, Python и Emacs Lisp имеют собственные профайлеры, включенные в их базовые дистрибутивы. Такие профайлеры переносятся на все платформы, где работают данные языки. В языке Java имеется встроенное профилирование. Tcl все еще не имеет поддержки профилирования.

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

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

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

Например, утилиту make можно запустить из Emacs с помощью команды ESC-x compile [Enter]. Данная команда запускает make(1) в текущем каталоге, собирая вывод в буфер Emacs.

Сама по себе данная операция не была бы очень полезной, но Emacs-режим make распознает формат сообщений об ошибках (указывая исходный файл и номер строки), которые генерируются Unix C-компиляторами и многими другими инструментами.

Если какая-либо выполняемая make инструкция генерирует сообщения об ошибках, то команда Ctl-X ` (Ctrl-X-обратная кавычка) пытается выполнить их синтаксический анализ и последовательно переходит к каждой ошибке, открывая окно соответствующего файла и перемещая курсор к строке с ошибкой[133].

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

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

Emacs-режим Grand Unified Debugger (большой унифицированный отладчик) поддерживает все основные отладчики С: gdb(1), sdb(1), dbx(1) и xdb(1). Он также поддерживает символический отладчик Perl с использованием модуля perldb и стандартные отладчики для Java и Python. Средства, встроенные в сам Emacs Lisp, поддерживают интерактивную отладку кода Emacs Lisp.

К моменту написания книги (середина 2003 года) еще не существовало поддержки для Tcl-отладки из Emacs. Конструкция Tcl такова, что вряд ли когда-либо такая поддержка будет добавлена.

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

К счастью, Emacs может помочь и в данной ситуации. Код, встроенный в Emacs, реализует простой в использовании пользовательский интерфейс к системам SCCS, RCS, CVS или Subversion. Команда Ctl-x v v пытается определить логически следующую операцию контроля версий, которую необходимо выполнить для редактируемого файла. В число данных операций входят регистрация файла, его отметка и блокировка, а также возвращение (комментарии по изменениям принимаются во всплывающем буфере)[134].

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

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