Хабрахабр

[Из песочницы] Логирование как способ отлаживать код

Почему так важно запретить самому себе отладку руками?

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

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

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

Проблематика: Сложно отлаживать составной код

Возможный алгоритм решения проблемы:

  1. Разбить на отдельные части
  2. Выкидываем отладку, просто запрещаем пользоваться режимом Debug
  3. Анализируем отдельные части (придумываем для них невалидные ситуации, граничные случаи)
  4. Пишем тесты на каждую отдельную часть всего алгоритма
  5. В тестах иногда приходится узнавать промежуточные данные, но…
    Отладка нам боле недоступна, поэтому втыкаем Trace в те части, где возникает подозрение на некорректное выполнение алгоритма
  6. По трассировке нужно понять причину проблемы
  7. Если не понятно, то чаще всего либо стоит написать ещё тест, либо выполнить трассировку на один этап раньше

Решением является автоматизированное тестирование с использованием логирования. Вы пишите тесты на все (или почти все) ситуации, которые приводят к проблемам. Плюс, если возникает потребность в отладке, то вы трассируете до тех пор, пока не разберётесь в проблеме.

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

Вы знаете, что по отдельности все реализации интерфейсов работают (т.к. Давайте посмотрим пример. Но при взаимодействии всего вместе возникает некорректное поведение. написаны тесты, доказывающие это). Нужно логировать ответы от «корректных» интерфейсов: Что вам нужно?

void Register(User user)
"); } // а вот это уже можно и залогировать, // т.к. от этого зависят дальнейшие детали алгоритма var roleInOtherService = _removeService.GetRole(user); _log.Trace($"Remote role: {roleInOtherService}") switch (roleInOtherService) { case "...": break; ... } // тут нам не критично, если пользователю не добавили // определённые привелегии в каком-то удалённом сервисе, // но мы бы хотели знать об этом foreach (var privilege in Privileges) { var isSuccess = _privilegeRemoteService.Grant(user, privilege); if (isSuccess) { _log.Trace($"Add privilege: {privilege} to User: {user}"); } else { _log.Trace($"Privilege: {privilege} not added to User: {user}"); } } ...
}

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

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

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

В таком случае выполняйте трассировку только в рамках отладки, а затем подчищайте за собой. Что если нам не нужен этот мусор?

Плюсы

Минусы

Есть возможность проследить выполнение алгоритма без отладки

Приходится писать код трассировки

В production логи будут собирать иногда нужные данные

В production логи будут собирать иногда ненужные данные

Время на отладку сокращается, т.к. вы часто запускаете код и тут же видите результаты его выполнения (всё как на ладони)

Нужно подчищать за собой. Это иногда приводит к повторному написанию кода трассировки

Коллеги могут прослеживать выполнение алгоритма по логам

Коллегам приходится смотреть не только на сам алгоритм, но и на трассировку его выполнения

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

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»