春节长假的最后一天，写完了产品的思考，换换方向，重新开始修炼之道，为明天的新年重启热热身。
调试这一节讲了非常多的内容，在前一篇里谈到了心态问题，在这一篇里，我想把几条相近的提示归拢一下，探讨一下调试中非常重要的准则叫事实说话。
事实说话的准则对应了好几个tips，分别来告诉我们哪些是能够相信的事实。
提示 32 读一下那些该死的出错信息。非常直白而有用的提示。通常来说错误信息包含了第一手的事故现场资料，比如我们的exception的stacktrace，非常清晰的标注了错误的类型，出错的类甚至是行数。应该说80%的错误信息能直接帮我们定位并解决一个问题。有stack trace的错误调试是比较幸福的。稍微说远一点，在没有出错信息的时候我们很多时候尝试植入一些调试信息是帮我们定位问题的有效手段。出错信息和调系统日志是显然的事实之一。
提示 31 修代码前先让代码在测试中失败。这是另一类获取事实的方法，叫做复现，通常来说一个错误能复现，基本上距离修复只有一步之遥了。当然复现有不同的级别，页面操作层面的复现和单元测试层面的复现不完全相同，不过即使只要最外层的复现也是一个非常有用的事实信息。
不过我还想提到的一点是不要把不能复现的问题等同于低优先级问题，不能复现说明我们没能把握问题的核心，和问题是不是低优先级没有关系。
提示 34 不要假设，要证明。这个tip更直白，和我提到的事实说话基本上是一个意思，不过假设和证明是一对好兄弟，也是我们思考问题的手段，很多时候我们是首先做了假设，然后再去证明的，那么提示34提到的核心是不要只假设不证明。只有证明了的假设才是事实，否则永远只是假设，对于问题的修复没有意义。
提示34 在我们日常的开发中我能听到很多的例子：
比如年前那个重复发送费用的产品问题，出了问题之后我们查了TMS的消息记录，发现我们只有一条发送记录，我们的想法就是这个问题出在对方这边，我们没问题，然而发送记录能证明问题出在对方这边吗？不能，发送记录只能证明TMS发到EAI是好的，真正能证明我们无辜的证据是eai与对方之间的消息记录，可能是FTP日志或者WebService调用记录。最后的结果也证实了问题还是出在我们这边。
可能有些同学认为说问题出在TMS这边不恰当，因为实际上出在eai 这边，有这样想法的同学请自我反思一下。在TMS与外部系统交互的过程中，只有TMS和外部系统两个party，eai是作为TMS的一个组件而存在的，我们可以内部谴责framework，对外这个锅是没法甩的。
小结一下：
事实说话，错误信息，程序日志，错误复现等等都算是事实。
没有事实，说明问题并没有真正被识别清晰。
事实不足以支撑的假设都仅仅只是假设，光有假设不要急着甩锅，证明了之后再甩。
网友评论