Протоколирование сценариев собственной разработки

Все разработчики знают что такое стек вызовов IS-Builder. И если большинству прикладных программистов он говорит довольно мало, то разработчикам платформы без него просто не обойтись. Начав в свое время писать на ISBL, я поначалу не утруждал себя тем, чтобы заботится о протоколировании работы сценариев. Особенно тех сценариев, задача которых один раз отработать и быть навсегда (как я полагал) забытыми. Прежде всего, это сценарии первоначального импорта данных из различных систем в DIRECTUM. Но практика показала, что лучше потратить на 10% больше времени на разработку сценария с поддержкой собственного лога, чем впоследствии убить в 10-20 раз больше времени на то, чтобы разобраться с ситуацией "что-то странновато он работает".

Приведу пример того, какие правила ведения логов я применяю сейчас.

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

[Отключение исключений]

[Создание файла общего лога]

[Цикл по всем обрабатываемым записям]

[Cоздание файла лога обработки записи]

[Вызов функции обработки, в которую передатся текущая запись и имя файла лога обработки записи]

[Внутри функции  прохождение всех этапов алгоритма функции записывается в файл лога обработки записи]

[Проверка исключений. Если в работе функции возникли исключения, то файл лога обработки записи дописывается к файлу общего лога. Если исключений не возникло, то файл лога обработки записи удаляется]

[Конец цикла по всем обрабатываемым записям]

В итоге можем получить 3 результата:

• файл общего лога пуст и отсутствует файл лога импорта записи. Это означает, что все успешно импортировалось;
• файл общего лога не пуст и отсутствует файл лога импорта записи. Это означает, что сценарий отработал до конца, но часть записей не импортировалась;
• файл общего лога пуст или не пуст и присутствует файл лога импорта записи. Это означает, что сценарий прервался в момент импорта очередной записи.

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

Правила ведения логов, которые демонстрирует данный сценарий:

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

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