Используйте специальные переменные окружения

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

 использует функцию с названием для получения оптимального размера буфера для ввода/вывода. Для небольших файлов функция возвращает размер файла. В противном случае, если файловая система определяет размер для использования при вводе/выводе, возвращается это значение (член структуры, см. раздел 5.4.2 «Получение информации о файле»). Если этот член недоступен, возвращает константу из. Оригинальная функция (в) выглядела следующим образом:

Константа является «размером блока по умолчанию»; то есть значением из или. Для терминалов (строка 23) или файлов, которые не являются обычными файлами (завершается неудачей, строка 27) возвращаемое значение также равно. Для небольших обычных файлов используется размер файла. Во всех других случаях возвращается. Знание «оптимального» размера буфера особенно полезно в файловых системах, в которых размер блока больше.

У нас была проблема, когда один из наших контрольных примеров отлично работал на нашей рабочей системе GNU/Linux и на любой другой системе Unix, к которой у нас был доступ. Однако, этот тест последовательно терпел неудачу на других определенных системах.

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

Нам был нужен способ воспроизведения проблемы на своей машине разработки, система с неудачей находилась в стороне за девять часовых поясов, а интерактивный запуск GDB через Атлантический океан мучителен. Мы воспроизвели проблему, заставив проверять значение специальной переменной окружения. Когда ее значение равно, всегда возвращает размер файла, каким бы он ни был. Если значением является какое‑нибудь целое число, функция возвращает это число. В противном случае, функция возвращается к прежнему алгоритму. Это дает нам возможность запускать тесты, не требуя постоянной перекомпиляции. Например,

AWKBUFSIZE=42 make check

Это запускает тестовый набор с использованием размера буфера в 42 байта. (Тестовый набор проходит.) Вот модифицированная версия:

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

Строки 42–54 выполняются лишь при первом вызове функции. Строка 43 обеспечивает это условие, устанавливая в значение. Строки 45–54 обрабатывают переменную окружения, разыскивая либо строку, либо число. В последнем случае оно преобразуется из строкового значения в десятичное, сохраняясь в. (Возможно, нам следовало бы использовать здесь; в свое время это не пришло нам на ум.)

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

Строки 60–70 определяют; эта часть не изменилась. Наконец, строки 72–76 возвращают размер файла, если это приемлемо. Если нет (строка 78), возвращается.

Мы действительно устранили проблему[174], но между тем оставили на месте новую версию, чтобы можно было убедиться, что проблема не возникнет вновь.

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

Добавьте код журналирования

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

• Всегда записывайте сведения в специфический файл. Это простейший способ: программа всегда записывает регистрационную информацию. Затем вы можете при возможности просмотреть файл.

Недостаток в том, что в какой‑то момент регистрационный файл займет все дисковое пространство. Следовательно, у вас должны быть несколько файлов журналов, причем программа периодически должна переключаться между ними. Брайан Керниган рекомендует называть файлы журнала по дням недели:, и т.д. Преимуществом здесь является то, что вам не придется вручную удалять старые файлы; вы бесплатно получаете недельную стоимость файлов журналов.

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

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

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

• Для журналирования используйте; конечное расположение сообщений журналирования может контролироваться системным администратором, (является довольно продвинутым интерфейсом; см. справочную страницу syslog (3)).

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

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