从调试说起
前段时间读了一篇云风的Blog：断点单步跟踪是一种低效的调试方法。文章中的观点引发了我的深思，是目前我今年阅读到的最好总结。这些观点如果没有经过合适的训练，比如我，是需要很长时间的实践和历练才能真正的体会并在实际项目中贯彻的。
在2012年之前，我自己在项目中写日志完全的“佛系”写法：想写就写，不想写就不写。后来参与一个架构师架构好的项目的时候，发现这个架构师在项目中加了非常多的日志，我说的是非常，日志和应用的代码数量达到了1/10左右了。你能想象一个佛系日志程序员看到每隔10行就来1行日志震惊么。虽然震惊但是项目架构的也特别好，所以也没有太多的抱怨，跟着代码规范和已有格式写呗。当时谈不上反感和好感，这其实源于我的一个工作习惯，我对代码风格虽有自己的偏好，但是不固执于此。我的理念也很简单：工作中每推动一项改变不可能都得到所有人都赞同，不能因为意见不同就不工作了，也不是按照要求工作就表示赞同你的意见。
后来当项目随着复杂度的提高和在生产环境中的使用，越发的发现以前感觉像是沙子的日志，现在却像散落的珍珠。当你再黑暗复杂的环境中找寻一些错误和信息的时候闪闪发亮。从那以后我逐渐在自己的项目中引入日志。虽然还是相对佛系，但是几乎每个会上到生产环境的应用，我都会加上日志。这给我省去了非常多的去客户现场的时间，每每客户遇到问题的时候，在询问过情况后，我都会让客户将日志文件发给我，超过一半以上的情况，我看看日志就可以很好的定位问题，连代码都不用打开。
随着几年间对日志的重视，我有了一些自己的总结。
怎么样写好日志
1 了解你的日志系统
几乎所有应用型语言，你几乎都可以找到趁手的日志系统，要么集成在标准库中，要么作为第三方类库。我自己是看项目的规模，优先考虑标准库。另一个需要考虑的是日志的存储，这个也非常依赖于项目的规模，通常中小型项目还是推荐文本型日志，存储直接用本地或者网络文件系统。在记录日志之前，你需要熟读日志的文档，并做一些设计决定。比如：
- 日志的存储，并由此而带来的日志rotation。
- 日志的检索，在你需要的时候尽快找到对应的日志。
- 日志对应用本身的影响，比如性能，日志系统本身异常。
2 设定日志的等级
对于日志系统来说有一个悖论就是：记得多浪费时间和空间，找起线索来也是不小的负担。记得少的话，会丢失一些关键信息的话发挥不到日志的最大作用了，特别是一些生产环境中的情况，更是需要更好地，更详尽的日志。对于通常的应用来说，我自己都拿空间和程序运行时间来换的业务的透明度——通过日志了解到业务是怎么样抽象成代码并运行的。
为了方便后期的检索，最简单莫过于所有日志系统都支持的日志严重等级分类。知道什么时候Fatal，什么时候是个Error，什么时候该Warn一下了，什么时候仅仅是一个Info。这里面有几个代码等级的忠告：
- 千万别吃掉异常，该抛一定要加上日志，抛出去。
- 用
Nullable或者Optional解决“百万美元”的空引用问题。
这里还有一个技巧就是使用类似Sentry或者是Rollbar这类在线异常收集工具帮助你收集代码层次的异常。
3 了解你的业务和代码
作为开发者，通常是对业务和代码都有较好了解的人。通过对业务的了解，找到哪些业务面的checkpoint，加上日志，让业务在你的日志面前变得清澈和透明。通过对代码的了解，让哪些bug被一个个格子划开，即使不能通过日志直接抓到bug，也能将bug限制在两行日志中间。
通常下面的情况可以考虑加一行日志：
- 应用程序，启动和关闭，和其他重要行为，从操作系统来看。
- 比如程序版本，加载的模块，影响行为的配置文件，环境变量
- 重要工作进程/线程的创建，启动和退出。
- 函数
- 程序的参数，函数输入决定输出，输入都不对，输出怎么可能对呢？
- 影响函数行为和结果的副作用点，比如文件是否存在，查找或生成的文件的位置。
- 有副作用的函数，比如操作网络，操作磁盘，数据库操作，有时候越是难的bug，越是这些觉得不可能出错的地方出错。
- 环境
- 第三方回传的时候检查一下，返回数据了么，返回大小是多少，调用时间用了多少？
- 关键业务点
- 留下点脚印，打一些Info类的日志。
- 数据驱动着应用，常常bug在数据中。加一些日志在已有的数据上，即使不记录具体内容，也要记一下大小。
- 别在同一个地方跌倒两次。抓到一个bug，或者业务漏洞修复，写个测试区覆盖或许很难，但是记一行日志不费多少电。
4 该上调试器的时候还是得上
别固执于日志，总是需要平衡日志的投入和产出，一行代码一行日志毕竟不够经济和效率。总有一些角落需要你带上调试器，打开手电筒，慢慢去探索。
Comments: