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

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

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

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

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

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

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

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

  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 нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] Как работают браузеры — введение в безопасность веб-приложений

Давайте начнем серию статей по безопасности веб-приложений с объяснением того, что делают браузеры и как именно они это делают. Поскольку большинство ваших клиентов будут взаимодействовать с вашим веб-приложением через браузеры, необходимо понимать основы функционирования этих замечательных программ. Chrome и lynx ...

[Перевод] Как мы две недели охотились на баг NFS в ядре Linux

Подробное описание поисков бага из задачи GitLab, которые привели к патчу для ядра Linux Они пытались клонировать некоторые репозитории через Git, и вдруг появлялось непонятное сообщение об устаревшем файле: Stale file error. 14 сентября служба поддержки GitLab сообщила о критической ...