保存什么呢？这条消息在开发者看来是能说明一些问题的，但是对于正在苦苦查看产品问题的可怜家伙来说，却毫无用处。
这就解释了你想要存储的东西（这里是一个 Person，是一个 JPA 实体）以及这个 Person 实例相关的内容。
请注意相关这个单词，并不是指泛泛的全体：我们不应该让无价值的信息使日志文件变得乱糟糟，比如说完整打印所有的实体字段。
在 Java 系统中提供的所有日志管理工具和引擎都有日志等级（ERROR、INFO……）的概念，这将有可能过滤掉等级过低的消息。
日志过滤等级则需要取决于代码的开发阶段：成品与仍处在测试、集成下的代码日志等级就不能相同。
测试、集成阶段：我的代码是 DEBUG 等级，第三方库是 WARN（或者如果需要的话是 INFO）。
注意：个人而言，我不使用 TRACE/FINEST 等级（我并不是唯一持这种观点的人，可以参考 这里 的例子）。
我并没有发现 DEBUG 和 TRACE 有多大的区别，而年轻团队的常常苦恼于到底是使用 DEBUG 还是 TRACE 。
编码时，我们常常会使用 logger 或是 System.out 在代码中添加日志消息，来更好地掌握应用程序在执行、调试期间发生的状况。
这些消息显示被调用的方法并且备份内部变量及方法参数值，主要是为了追踪应用程序的行为。这在非测试驱动开发中相当受欢迎。
所以，这条规则简单来说就是：一旦你已经完成开发工作，在将代码提交到使用中的 SCM 系统（git、svn……）之前，要去除所有临时的和不必要的日志消息。
这条规则并不是要求去除所有的 DEBUG 消息，只是针对那些在应用程序完成和发布后就没有意义的消息，或者是说当我们有理由相信应用程序能正确运行时就失去意义的那些消息。
根据第2条规则，在产品日志中，我们只会显示 ERROR、WARN、INFO 等级的消息，但是在代码中我们也可以使用一些不会影响产品运行的 DEBUG 消息。
每次你想要 log 一个 DEBUG 消息时（在使用了规则3后的留下的所有消息），需要在前面添加一个检查来明确是否启用了 DEBUG 日志：
我们应该查阅所选择的日志管理工具、引擎的 javadoc 文档，了解使用它们 logger 的最有效的方法。
网友评论 ()条 查看