在什么阶段你添加日志记录＆amp;在OO中追踪？

Question

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

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

我发现自己在我的应用服务中使用描述性的logger.INFO“从存储库中获取蛋糕”来装饰方法。一些工作......“从存储库中获得了5个蛋糕。”，然后是一个未处理的expcetion处理程序，用于logger.FATAL的应用程序doam，用于冒泡的意外删除。

然而，我通常会在开发结束时而不是在开发阶段结束时返回并应用这些，但我可能只有十几个。我发现我很少装饰任何较低级别的类，例如使用logger东西实现ICakeRepository，因为它似乎毫无意义。

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

Answer 1

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

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

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

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

我关心日志记录的理由部分解释如下：

• Separate ‘debug’ and ‘release’ builds?
• Should one test internal implementation, or only test public behaviour?

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

---

你说，

  

我发现我很少装饰任何较低级别的类，例如使用logger东西实现ICakeRepository，因为它似乎毫无意义。

我说，

  

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

我想我最好用“层”来解释我的意思，它可能与你的“低层”类相同或不同。

例如，我的系统可能包含以下图层：

• UI
• 业务层（操纵数据的规则）
• 数据访问层（用于数据库I / O）
• 数据库

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

• 在用户和UI之间（即UI事件，鼠标和键盘）
• 在UI和业务层之间（请参阅“简单对话框”）
• 在业务层和DAL之间
• 在DAL和数据库之间

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

在任何情况下，我正在记录的是每个组件的公共外观的API，这有利于记录，原因如下：

• 不太复杂（外观往往比底层/内部实现简单）
• 良好的覆盖范围（如果我记录整个外观，如果进入组件的唯一方法是通过其外观，那么我知道我已经记录了组件中的所有内容）
• 与Conway's Law配合良好：在调试具有多个组件的系统时，每个组件由不同的团队开发，其中一个常见问题是“哪个组件出错，因此哪个团队需要对其进行调试？ “

Answer 2

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

Answer 3

记录和追踪应该是跨领域的问题。如果您使用面向方面的编程，则可以以声明方式随时添加/删除它们。

Answer 4

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