В настоящее время я разрабатываю спокойный сервис с использованием Spring MVC.
Я читал, что ведение журнала - это перекрестный разрез, поэтому мне было интересно, не является ли плохой практикой иметь операторы журнала, такие как log.info("A variable value"), внутри методов фасада службы.
Должны ли мы удалить эти операторы журнала и поместить их в объект типа перехватчика, единственная ответственность которого - ведение журнала?
Заполнен ли метод сообщениями log.debug, в обязанности которых входит отслеживание неправильной практики выполнения метода? Если это так, как мы можем передать эту ответственность перехватчику, если перехватчик имеет доступ только к параметрам метода




Это не обязательно плохая практика, но вы должны попытаться избежать ошибки твиттера, когда в сообщениях журнала были пароли пользователей в виде обычного текста до шифрования.
Это должен быть комментарий, а не ответ.
это хоть ответ?
Если вы не понимаете, что делает метод, существует серьезная проблема, вы потеряли контроль над программным обеспечением.
Бывают случаи, когда он необходим, но его следует удалить как можно скорее. Среди прочего, операторы журнала усложняют понимание кода, добавляя нелогический «шум».
Методы должны быть достаточно небольшими, чтобы их можно было легко понять с небольшими усилиями, за некоторыми исключениями. См. «Дядюшка» Боба Мартина.
Я был задействован в одном проекте, потому что производительность неуместна. Я решил эту проблему за день, это было ведение журнала, я удалил его, и производительность увеличилась более чем в 25 раз.
Ведение журнала полезно в коде для целей отладки. АОП не может полностью заменить ведение журнала внутри метода. Для журнала входа и выхода я предпочитаю АОП. Обычно я пишу аннотацию и совет Around, в котором регистрируются имя класса, имя метода и параметры при входе и возвращаемое значение (или трассировка стека исключений) на выходе. Это в значительной степени сокращает шаблон журнала. После этого потребуется минимальная регистрация.