6

我对您在开发的哪个阶段向您的应用程序添加日志记录和/或跟踪感兴趣？

我正在使用 .Net 堆栈和 log4net（通过 commons.logging）。通常采用 TDD 方法进行开发，虽然不可否认不是 100%，但有时我知道在没有测试覆盖的情况下会飙升。我的应用程序都位于服务器端，例如 Web 服务、使用总线消息的 Windows 服务、asp.net mvc 业务管理应用程序。ETC..

我发现自己在我的应用程序服务中使用描述性 logger.INFO "Getting cakes from repository" 来装饰方法。一些工作..“从存储库中获得了 5 个蛋糕。”，然后应用程序域的未处理的异常处理程序到 logger.FATAL 以处理冒泡的意外异常。

但是，我通常最终会在开发结束时而不是在开发开始时返回并应用这些，我可能只有一两个。我发现我很少用记录器来装饰任何较低级别的类，例如 ICakeRepository 的实现，因为它似乎毫无意义。

对于通过配置打开的跟踪，我正在考虑使用 IOC 框架拦截方法调用和实例创建，这应该处理现场故障排除而不是大量跟踪人口。

4

4 回答 4

2

我的软件是分层的，每一层之间都有一个定义良好的 API。我倾向于从一开始就为这些 API 实现日志记录，这样对于任何给定的事务，我都可以看到它是如何导致每个底层的 API 调用的：如果有错误，这将有助于将其缩小到特定的层。日志记录还将通过显示导致问题的所有先前正常活动的日志来帮助重现问题。

我还在我可以的每一层中添加断言，并记录断言失败。

因此，日志文件通常显示对公共 API 的一系列调用，并从内部生成错误消息：这通常足以诊断问题。

除此之外，我会根据需要添加调试级别的日志记录：在开发期间和/或发布后调试特定问题。

我关心日志记录的原因部分解释如下：

要修复已发布软件中的任何错误，我依赖于日志文件；开发中的软件通常也是如此。

你说，

我发现我很少用记录器来装饰任何较低级别的类，例如 ICakeRepository 的实现，因为它似乎毫无意义。

我说，

我的软件是分层的，每一层之间都有一个定义良好的 API。我倾向于从一开始就为这些 API 实现日志记录......

我想我最好解释一下“层”的含义，它可能与您的“低级”课程相同，也可能不同。

例如，我的系统可能有以下几层：

  • 用户界面
  • 业务层（操作数据的规则）
  • 数据访问层（用于数据库 I/O）
  • 数据库

在这种情况下，我将拥有以下可能值得记录的接口或 API：

  • 用户和 UI 之间（即 UI 事件、鼠标和键盘）
  • UI 和业务层之间（参见“Humble 对话框”）
  • 业务层和 DAL 之间
  • DAL 和数据库之间

或者，系统可能是连接两个对等端点的组件链（对于“顶层”和“底层”层不太明显）。

无论如何，我要记录的是作为每个组件的公共外观的 API，这有利于记录，原因如下：

  • 不太复杂（外观往往比底层/内部实现更简单）
  • 良好的覆盖范围（如果我记录了整个外观，并且如果进入组件的唯一方法是通过它的外观，那么我知道我已经记录了进入组件的所有内容）
  • 与康威定律配合得很好：当调试一个包含多个组件的系统时，每个组件都由不同的团队开发，经常出现的问题之一是，“哪个组件有问题，因此需要哪个团队来调试它？”
于 2009-06-28T14:11:45.703 回答
1

我们是 TDD，所以我们基本上不再做太多的日志记录了。也许只是在顶级异常处理程序和一些战略位置。

于 2009-06-28T12:03:59.160 回答
1

日志记录和跟踪应该是跨领域的关注点。如果您使用面向方面的编程，您可以随时以声明方式添加/删除它们。

于 2009-06-28T14:05:38.120 回答
0

我不会说“从存储库获取蛋糕”最适合 INFO。它更适合DEBUG甚至TRACE。通常你会想使用 INFO 来记录功能性的东西，例如“没有给用户 A 留下蛋糕”。恕我直言，非功能性的东西和技术流程应该具有较低的严重性。我不会使用 FATAL 来记录异常，除非你到了应用程序完全死机的地步。看到 FATAL 会很混乱，然后系统仍然活着并且在踢。ERROR 是更好的选择，有时甚至是 WARNING，这取决于异常的严重程度。至于 AOP 拦截器，上次我检查过 - 这些东西极大地影响了性能。这是一个很酷很性感的概念，但对我来说并不实用，不确定它是否比解释 AOP 好处的书籍和文章中的演示和琐碎示例更进一步。所以，在完全依赖它之前，我会仔细检查。

于 2009-06-28T11:23:59.133 回答