开发日志是很能体现一个开发者能力和逻辑思维的项目。写得好的程序，日志有序完备，能够用于跟踪关键路径，方便定位问题，有时还可以帮助进行性能优化。而比较差的代码，要么日志残缺不全，要么絮絮叨叨还把握不了关键路径，无助于定位问题。本文主要讲讲我对开发日志的一些心得。
1、使用不同级别的日志，关注高级别缺陷日志
现在很多开发环境的日志类提供了多级别的日志输出（如果没有日志类或者日志类不支持日志级别，完全可以自己实现，其实就是写文本文件）。我觉得日志级别是很有用的，常态地检查程序运行产生的高级别缺陷日志并进行修复，可以未雨绸缪，大大提高程序的健壮性。在开发中我是这么定义日志级别的：
ERROR（出乎意料的出错，比如打开用户本地数据库失败） > WARN (事情不大对，比如网络掉线了，但还在预料之中） > INFO （正常，只是打印下，比如：开始同步、结束同步） > DEBUG （用于调试，一般是临时性） > VERBOSE (在调试控制台看就好了）
ERROR级别的错误：严重关注，要全部处理掉，说明程序有错或者有未正确处理的异常。
WARN级别的错误：关注，看看是否正常。比如掉线是正常的。一秒掉线几十次就不正常了。
INFO： 不大关注，除非正在开发某方面功能。一种常见用途是通过其来显示运行时间。
DEBUG： 不重要，一般调试某个功能时才关注。
VERBOSE： 不重要，一般在控制台看看就好了。
如果没有VERBOSE，可以用DEBUG替代，两者作用相当。
少数时候还会使用更严重级别的错误：FATAL（致命错误），比如发现后台任务迟迟不结束（可能发生死循环或者死锁）。
2、客户端日志彩蛋，线上问题不抓瞎
Android和IOS自带的Log类，只是输出到控制台。这样如果发布到线上后，客户使用过程中出了问题，就没有日志来帮助定位问题，有些难以重现的问题就很难处理。所以我在Android和IOS上都重新封装了日志类，该日志类在调用原生的Log类输出之余，会将日志输出到文件（按日保存，每天一个log文件，应用会定时删除太旧的日志文件以免占了太多空间）。然后在应用中实现查看和发送日志文件的彩蛋功能。
如果应用在设备深度睡眠（不连USB线，锁屏一段时间后）前后产生一些比较灵异的Bug，将日志写到文件的做法对于定位问题也会很有帮助。如果连着USB线，设备就不会进入深度睡眠了，所以无法直接调试。
3、是否打印异常的堆栈信息（For JavaOnly）
不管是Java服务端的Log4j，还是Android的Log。都支持输出异常的详细堆栈信息。但是打印堆栈信息是个比较慢的操作（Java框架层层封装，堆栈达到几十层的都见过），而且其中不必要的信息很多。所以不应该每次都打印异常的详细堆栈信息，要区分对待：
如果属于“万万没想到”这种性质的异常，应该打印异常的堆栈信息以便问题定位。这种情况下日志级别应该是ERROR。
如果是“意料之中”的异常（可能是一开始就想到，比如文件IO异常。也可能是通过ERROR日志知道），一般是不需要打印异常的堆栈信息的。可以只打印异常的getMessage。这种情况下日志级别一般是WARN以下级别。
4、日志也是需要不断维护的
一个好的开发习惯是周期性的检查日志，通过日志发现并修复潜在的问题，并对日志进行维护工作。具体有：
1、找到ERROR以上级别的日志，发现并修复潜在的问题。目标是要使系统的ERROR日志不断减少，趋近于没有。
2、删除冗余、过时的日志。如果日志的数量太大，就很难简单地用肉眼看出问题，也影响性能。可能某些模块在开发过程中日志的量比较大，那么在相关功能比较稳定之后，可以删除trace性质的日志，只保留其关键路径上的日志。
5、日志可以使用中文
这点蛮有趣的，好像不少代码里日志都习惯使用英文，可是英文水平又不行，看得很难受。直接用中文就好了。相比奇怪的英语，“错误：传入的用户名为空”好写又好看。
再补充一些谈话内容：写日志也是编码能力的一方面，同样需要经验的积累。如果日志写得好，注释写得好，代码肯定也写得好，那就已经是高级开发了。什么样的日志算好的呢？如果测试或者运行中发生的Bug，可以看下日志，马上就定位到问题，这就是好日志。当然不可能百发百中。如果能够帮助定位90%以上的问题，我觉得这个系统的日志就做得挺好的了。日志要切中要点，有些人罗里啰嗦，没用的日志打了一堆，反而干扰发现问题和排错。日志能力需要经验和用心思考，当出现日志无法定位问题的时候，要自省应该在哪些地方加上日志，可以帮助定位类似问题。
