Всем программам необходим встроенный лог, чтобы мы могли
наблюдать за их функционированием. Особенно, когда что-то идет не так. Великий
программист отличается от плохого тем, что добавляет лог и инструменты, которые
упрощают отладку программы в случае сбоев.
Когда программа работает как следует, почти невозможно
отличить качество протоколирования. Однако, различие между хорошими и плохими
программистами проявляется, как только в программе происходит сбой или вы
получаете неправильные результаты.
Пример №1: "Давайте создадим отладочную версию"
Например, тестировщик пришел ко мне и сообщил, что вызов не
работает. Мы просмотрели логи и увидели, что проблема в соседнем модуле. Вызов
другого модуля для получения списка значений возвратил пустое значение. Когда
мы включили протоколирование в соседнем модуле и повторно выполнили тестовый
сценарий, информация исчезла.
Непонятно, почему возвращалось пустое значение - были ли
аргументы ошибочными? Или произошел сбой во внешней системе? Может ошибка в
соседнем модуле? Что все-таки произошло?
Спросив разработчика, ответственного за код, мы услышали
следующее: "Тогда нам придется создать отладочную версию, чтобы понять, в
чем дело". Неправильно! Одни только логи должны помочь нам определить
источник проблемы.
Если бы подобное случилось в основной рабочей системе, на
добавление отладочной версии ушло бы много усилий. Код обязан содержать
достаточно информации, чтобы вы по крайней мере понимали, из-за чего произошел
сбой.
Пример №2: Покажи мне, как мы к этому пришли
Один из наших продуктов находит самый дешевый маршрут для
доставки текстовых сообщений на мобильные телефоны. Варианты варьируются в
зависимости от текущего расположения телефона и оператора, к которому
принадлежит адресат.
Кроме того, есть исключения, запрещающие некоторые маршруты.
Как правило, система в каждом случае выбирает из нескольких тысяч возможных
маршрутов самый дешевый и доставляет сообщение.
Теперь, предположим, что сообщение доставили, используя
маршрут А, но считается, что лучше бы использовали маршрут B. почему выбрали
маршрут A? Если в логе нет никакой информации (кроме "был выбран маршрут
А"), нам остаются тысячи возможных маршрутов с их стоимостью, исключениями
и сложным алгоритмом. Удачи в поиске ответа!
Наш вариант лога включает все возможные маршруты в порядке
их стоимости. По мере того, как маршруты удаляются из-за различных ограничений,
они записываются в журнале вместе с указанием причины удаления. Когда вся
информация о входных данных и проделанных шагах внесена в журнал, становится
ясно, почему был выбран конкретный маршрут.
Почему нет?
Почему не все программисты пишут отлаживаемый код? Я могу
назвать три причины:
- Необходимо быть достаточно самокритичным, чтобы понимать, что в отдельных случаях код не будет работать как следует. Я думаю, у многих программистов с этим проблемы.
- Если вы сами тщательно тестируете свой код, вы убедитесь, что он работает (или не работает) при разных сценариях. Для каждого сценария принято добавлять вывод в лог. Если вы не тестируете сценарии, то и вряд ли добавляете логгирование.
- Многие программисты редко "диагностируют" собственный код в рабочей системе. Если у вас есть проблема в живой системе и журналы регистрации ничего не говорят о ее источнике, вы, наверняка, захотите добавить журнал, который поможет вам в подобной ситуации в будущем.
Ваш код отлаживаемый?
Естественно, бывает, что даже четкие и детальные сообщения в
журнале регистрации не позволяют до конца понять, почему произошел сбой. Вы по-прежнему
можете создать отладочную версию. Но, записи в журнале регистрации должны как
минимум намекнуть, в чем состоит проблема.
Комментариев нет:
Отправить комментарий