Коэффициент привязки кодов?

Ответ 1

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

Я согласен с тем, что то, что вы говорите, слишком мало для регистрации.

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

Ответ 2

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

Уровень DEBUG

• Любые параметры, переданные в Метод
• Любые числа строк из наборов результатов, которые я извлекаю
• Любые datarows, которые могут содержать подозрительные данные при передаче методу
• Любые "сгенерированные" пути к файлам, строки подключения или другие значения, которые могут быть собраны во время "сложения" среды.

Уровень INFO

• Начало и конец метода
• Начало и конец любых основных циклов
• Начало любых основных операторов case/switch

Уровень ERROR

• Обработанные исключения
• Недействительные попытки входа (если проблема с безопасностью)
• Плохие данные, которые я перехватил для отправки

Уровень FATAL

• Необработанные исключения.

Кроме того, наличие большого количества сведений о регистрации не позволяет мне спросить пользователя, что они делают, когда они получили сообщение об ошибке. Я могу легко собрать его вместе.

Ответ 3

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

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

Ответ 4

Кроме того, в эти дни мощные IDE и удаленная отладка - это то, что много протоколов действительно нескреса?

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

• Для изучения проблем в коде реального времени, когда приостановка с отладчиком приведет к результату вычисления (предоставлено, ведение журнала будет иметь небольшое влияние на синхронизацию в процессе реального времени, как это, но насколько это сильно зависит от программного обеспечения)
• Для сборок, отправленных бета-тестерам или другим коллегам, у которых нет доступа к отладчику
• Для сброса данных на диск, которые нелегко просмотреть в отладчике. Например, определенная среда IDE, которая не может правильно разобрать структуры STL.
• Для получения "ощущения" нормального потока вашей программы
• Чтобы сделать код более читаемым в дополнение к комментариям, например:

// Now open the data file
fp = fopen("data.bin", "rb");

Вышеупомянутый комментарий можно так же легко разместить в журнале:

const char *kDataFile = "data.bin";
log("Now opening the data file %s", kDataFile);
fp = fopen(kDataFile, "rb");

Тем не менее, вы в некотором роде правильны. Использование механизма регистрации в качестве прославленного регистратора трассировки стека создаст очень плохое качество лог файлов, так как оно не дает достаточно полезной точки простоя для изучения разработчиком. Таким образом, ключ здесь, очевидно, является правильным и разумным использованием вызовов регистрации, которые, я думаю, сводятся к усмотрению разработчика. Вы должны учитывать, что вы по существу делаете лог файлы для ; ваши пользователи не заботятся о них и, как правило, грубо неверно истолковывают их содержимое, но вы можете использовать их, чтобы хотя бы определить, почему ваша программа плохо себя ведет.

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

Ответ 5

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

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

Кроме того, для вашей информации добавление регистрации во время компиляции будет примером того, что называется Aspect Oriented Programming. Регистрация была бы "проблемой перекрестной резки".

Ответ 6

Когда у вас есть сценарий клиента (т.е. тот, чей компьютер вы не получаете физического доступа), единственные вещи, которые "слишком много регистрируются", представляют собой перекрашивающие функции и почти все, что их называют (что должно быть почти ничего). Или другие функции, которые называются 100 раз в секунду во время работы (запуск программы в порядке, хотя, чтобы иметь 100 вызовов для ввода/установки подпрограмм, зарегистрированных, потому что, по моему опыту, там, где возникают большинство проблем).

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

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

Ответ 7

Я лично считаю, что в первую очередь нет жесткого и быстрого правила. У меня есть некоторые приложения, которые регистрируют LOT, в и из методов, и обновления статуса через середину. Эти приложения, хотя и являются запланированными процессами, отключают руки, а журналы анализируются другим приложением, которое сохраняет успех/сбой.

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

Однако это действительно зависит от проекта.

Ответ 8

Сколько из этих строк регистрируется по умолчанию? Я работал над системой, очень похожей на то, что вы описали, - просто ее загрузка приведет к записи более 20 МБ журналов, если ведение журнала было запущено, но даже отладки мы не перевернули все эти модули для всех модулей, По умолчанию он будет регистрироваться при вводе модуля кода и основных системных событий. Это было здорово для отладки, поскольку QA мог просто прикрепить журнал к билету, и даже если он не был воспроизводимым, вы могли видеть, что происходит, когда проблема возникла. Если у вас серьезная многопоточность, то регистрация еще лучше, чем любая IDE или отладчик, с которыми я работал.

Ответ 9

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

Ответ 10

Я обнаружил, что регистрация гораздо менее необходима, так как я начал использовать TDD. Это значительно облегчает определение ошибок. Тем не менее, я считаю, что протоколирование может помочь понять, что происходит в коде. Несомненно, отладчики помогают дать вам представление о том, что происходит на низком уровне. Но мне легче, когда я могу сопоставить строку вывода с линией кода, если я хочу получить представление высокого уровня о том, что происходит.

Однако, одна вещь, которую я должен добавить, заключается в следующем: убедитесь, что ваши операторы журнала включают модуль, в котором работает оператор журнала! Я не могу подсчитать, сколько раз мне приходилось возвращаться и находить, где на самом деле лежит оператор журнала.

Ответ 11

Я думаю, что "logs to ratio ratio" - непонимание проблемы.

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

Затем ВСЕ, у вас есть возможность исправить ошибку, это информация, которую вы сами вложили в файлы журнала. Никаких сеансов отладки (которые в любом случае запрещены в производственных средах) - не выбирая входные данные - ничего!

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

Точно, ЧТО вещи зависят от сценария, но в основном достаточно, чтобы убедиться, что вы никогда не сомневаетесь, что происходит, когда:)

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

Отключение регистрации как чрезмерного, обычно делается теми, кому не пришлось исправлять ошибку, и ничего больше не нужно:)

Ответ 12

В моей работе я пишу много служб Windows. Для меня вырубка не роскошь; это на самом деле мой единственный пользовательский интерфейс. Когда мы внедряемся в производство, мы теряем доступ к отладке и даже к базам данных, на которые наши службы пишут и не регистрируются, мы не знали бы какой-либо специфики возникающих проблем.

Сказав это, я считаю, что наилучшим подходом является сжатый стиль ведения журнала. Сообщения журнала обычно ограничиваются бизнес-логикой приложения, например "полученное сообщение из учетной записи xxx", чем "введенная функция yyy". Мы выполняем исключения журналов, запуски потоков, эховые настройки среды и тайминги. Помимо этого, мы смотрим на отладчик, чтобы идентифицировать логические ошибки в фазах разработки и QA.

Ответ 13

Должен признаться, что при запуске программирования я более или менее регистрировал все детали, как описано "Дилли-О".

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

Как только система станет стабильной, я медленно начал удалять записи журнала, так как их добавление значения начало уменьшаться. (No Log4j в этот момент времени.)

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

В настоящее время мы имеем много гибкости при регистрации с такими пакетами, как Log4j, динамическое включение уровня журнала и т.д.

Но если программисты не используют его надлежащим образом, например, когда использовать, когда НЕ использовать INFO, DEBUG, ERROR и т.д., а также данные в сообщениях журнала (я видел сообщение в журнале вроде "Hello X", Hello XX, Hello XXX и т.д. ", Которое может понять только программист), соотношение будет оставаться высоким с меньшим ROI.

Ответ 14

Я думаю, что еще один фактор - используемый инструментарий/платформа и соглашения, которые приходят с ним. Например, ведение журнала, по-видимому, довольно распространено в мире J (2) EE, тогда как я не помню, чтобы когда-либо записывал оператор журнала в приложении Ruby on Rails.