14.6　总结

我们介绍了如何使用logging模块和更高级的面向对象设计技术。我们创建了与模块、类、实例和函数相关联的日志。我们用装饰器创建日志，这种日志作为一致的横切方面应用于多个类中。

我们介绍了如何使用warnings模块来显示配置有问题或者方法已经废弃。我们可以将warnings用于其他目的，但是必须注意滥用warnings而导致一种不知道应用程序是否正常工作的模糊情况。

14.6.1　设计要素和折中方案

logging模块支持审计、调试和一些安全需求。我们可以用记录日志的方式作为保存处理步骤记录的简单方式。通过选择性地启用和禁用日志，可以为那些处理真实世界的数据时需要了解代码是如何工作的开发人员提供支持。

warnings模块支持调试和维护的功能。我们可以用它提醒开发人员API问题、配置问题和其他潜在的漏洞来源。

当使用logging模块时，我们会经常创建大量不同的日志记录器，这些记录器都包含一些handlers。我们可以用Logger名称的层次结构引入新的或者专用的日志消息集合。一个类不能包含两个日志记录器是没有理由的：因为一个可以用于审计，另一个可以用于更通用的调试。

我们可以引入新的日志级别数字，但是必须非常小心。级别可能会混淆开发人员关注的（debug、info和warning）信息和用户关注的（info、error和fatal）信息。调试消息中有特定的一部分不需要一直显示的失败错误消息中。我们可以为详细信息或者可能是详细调试信息增加一个级别，但是这已经是关于级别的所有改变。

logging模块允许我们为不同的目的提供多个配置文件。作为开发人员，我们可以考虑用配置文件将日志级别设置为DEBUG以及为开发中的模块启用特殊的日志记录器。对于最后的部署，我们可以用配置文件将日志级别设置为INFO并且为支持更正式的审计或者安全审查提供不同处理程序。

我们会包含Zen of Python中的一些思想。

错误永远不应该被忽略。

除非是显式地忽略。

warnings和logging模块直接支持这种想法。

这些模块更倾向于全局的质量，而不是问题的特定解决方案。它们允许我们通过比较简单的编程获得一致性。随着我们的面向对象设计变得更大、更复杂，我们可以更专注于待解决的问题，而不用浪费时间考虑基础架构的问题。此外，这些模块允许我们修改输出，为开发人员或者用户提供有用的信息。

14.6.2　展望

在后面的章节中，我们会介绍可测试性以及如何使用unittest和doctest模块。自动化测试是软件的基本要求，在自动化测试提供足够的证据向我们展示代码正常工作之前，都不应该认为编码工作已经完成。我们会介绍一些更容易测试的面向对象的设计技术。