Большинство программ не имеют достаточного количества регистрационной информации.
Есть ли способ отслеживать эти неприятные ошибки кодирования намного быстрее?
Недавно от команды QA мы получили тикет об ошибке. Как обычно, в тикете описывалась проблема с нашим приложением, и к нему прикреплялось сообщение об ошибке. Как только я начал читать сообщение об ошибке, я решил поискать ту же ошибку в наших журналах. Сюрприз, сюрприз там было неприятным исключением.
На первый взгляд исключения дают нам подсказку о нашей проблеме, где она возникла, но много раз, если мы откроем код, мы не увидим четкого ответа на наши проблемы. Потому что в нашем коде много абстракций, и нам нужно копнуть глубже, чтобы увидеть, что вызывает текущую проблему.
Ошибки будут происходить, хотите вы этого или нет.
Многие большие проекты сложны и имеют много абстракций, и когда случаются необычные ошибки, их трудно отследить.
Мое решение для лучшего решения этих необычных ситуаций — добавить больше журналирования в ваш код.
Часть журнала.
Ведение журнала помогает вам в устранении неполадок вашего приложения. Он предоставляет информацию о том, как работают внутренние компоненты приложения, какие события происходят, какие исключения произошли и так далее.
Я работал со многими программными проектами, и все они страдают отсутствием логирования. Многие команды разработчиков программного обеспечения не используют все уровни журналов, обычно они придерживаются сообщений INFO и ERROR. Но даже в этом случае сообщения INFO используются редко, сообщения ERROR используются в исключительных случаях. Это основная проблема, почему трудно отследить эти непредсказуемые ошибки. Когда у вас недостаточно информации, вы потратите много часов на отладку своего кода.
Согласно Microsoft Docs, у нас есть следующие уровни журналов:
Мои любимые уровни журнала: INFO, ERROR, TRACE, WARNING.
Мое предложение состоит в том, чтобы сначала последовательно добавлять эти сообщения INFO, например, вызовы обработчиков журналов, вызовы методов. Это даст вам подсказки о ходе программы, и, если произойдет ошибка, вы можете увидеть из тех сообщений INFO, откуда возникла ошибка.
Используйте сообщения WARNING, когда ошибок нет, но в потоке вашего приложения произошло что-то некритическое. Например, если какая-то служба не отвечает, но это не критично для вашего приложения, скажите об этом серьезно и сделайте им предупреждение.
Используйте сообщения TRACE, если вы хотите регистрировать подробную информацию о своем приложении. В прошлом трассировка помогала мне отслеживать некоторые трудно находимые ошибки. Иногда вам нужна подробная информация о вашей программе, поэтому не бойтесь ее использовать.
Используйте сообщения ERROR для реальных ошибок. Если случится что-то плохое, используйте этот уровень журнала.
Что касается других уровней CRITICAL и DEBUG? Ну, иногда я использую уровень отладки, когда я что-то разрабатываю, и я хочу записать некоторую информацию о моем методе или потоке программы.
Я не использую CRITICAL, потому что ERROR достаточно, чтобы привлечь всеобщее внимание.
Вам или вашей команде решать, какие уровни использовать. Моя рекомендация - по крайней мере три из этих четырех. Одного решения конечно мало, надо его использовать.
В заключение я могу сказать, что логирование имеет решающее значение для современных сложных приложений. Наличие дополнительной информации о вашем приложении поможет вам быстрее отслеживать эти необычные ошибки. Потому что никто не хочет тратить часы или даже дни на отладку кода.
