Проектируйте облегченную диагностическую систему для выпускных конфигураций
Больше всего я ненавижу ошибки, которые случаются только на машинах одного или двух пользователей. Все остальные пользователи весело работают с вашим продуктом, но с машинами одного или двух происходит что-то уникальное, и понять это почти невозможно. Конечно всегда можно попросить пользователь отправить вам "плохо ведущую себя" машину, но эта стратегия не всегда практична. Если клиент находится в Карибском бассейне, вы могли бы добровольно отправиться туда и решить проблему. Никто не слышал, однако, чтобы компании так подходили к решению проблем качества их продукции. Не слышно ничего также и о толпах разработчиков, добровольно отправляющихся за Северный Полярный Круг, чтобы решить проблему.
Если сбойная ситуация воспроизводится только на одной или двух машинах, необходим способ просмотра потока выполнения программы на этих машинах. Многие разработчики уже прослеживают поток выполнения через файлы регистрации и запись в журнал событий, но я хочу подчеркнуть важность этого журнала для решения проблем. Возможности решения проблем регистрации потока выполнения резко возрастают, если вся команда подходит к прослеживанию такого потока организованно.
При регистрации информации особенно важно следование шаблону. Унифицированный формат способствует облегчению синтаксического анализа файла. В частности, можно автоматизировать чтение такого журнала при помощи Peri-сценария, выделяющего важные элементы.
Вообще необходимо регистрировать все (ну почти все), что связано с проектами, но, как минимум, следует точно регистрировать отказы и аварийные ситуации. Нужно также попытаться ухватить логический смысл действий программы. Например, если программа выполняет файловые операции, то не стоит регистрировать такие мелкие детали, как "переход к смещению 23 в файле...", но желательно регистрировать открытие и закрытие файла. Тогда, если последний вход в журнале оказался: "Preparing to open D:\Foo BAR.DAT" (Подготовка к открытию D:\Foo\BAR.DAT), то почти наверняка файл BAR.DAT испорчен.
Глубина регистрации зависит также от роста производительности, связанного с такой регистрацией. Современные инструменты контроля производительности позволяют быстро увидеть, достиг ли код регистрации подходящего уровня. Если это так, можно немного снизить глубину регистрации, пока не будет достигнут достаточный баланс между приемлемым уровнем регистрации и замедлением приложения.
Для регистрации в коде C++ я применяю макрос следующего типа (обратите внимание, что G_isLogging — глобальная переменная, которую могут видеть все модули). Наличие глобальной переменной позволяет сэкономить на вызове функции.
//Visual C++ макрос для регистрации событий
#define LOGGING(x) \
if ( TRUE == G_IsLogging) \
{ \
Logginglnfo ( x); \
}
Для Visual Basic, поскольку в этом языке нет макросов, я только проверяю глобальную переменную вручную. Читателю предоставляется возможность написать простое встраиваемое дополнение к IDE Visual Basic, которое позволяло бы с помощью кнопки добавлять все, кроме строк, для передачи в функцию регистрации.
Visual Basic. Пример вызова функции регистрации
i£ ( 1 = G_IsLogging) Then
Logginglnfo ( "Подготовка к открытию" & sFile)
End If
Глобальный флажок регистрации устанавливается одним из двух способов. Если потенциальные клиенты — опытные пользователи компьютеров, то можно установить его с помощью переменной окружения. Однако поскольку большинство пользователей — обычные люди, я рекомендую создать флажок установкой регистра.Кроме того, я создал бы небольшую утилиту для установки специального флажка регистрации и устанавливал бы ее вместе с приложением. При поступлении от пользователей сообщений о проблемах, инженеры службы технической поддержки могли бы выполнять эту утилиту, гарантируя включение регистрации. Наличие утилиты для установки флажка регистрации освобождает также штат службы поддержки от необходимости втягивать нового пользователя в длинную и потенциально опасную регистрацию по телефону.
