笔记|软件调试的技巧

这篇文章是《调试九法：软硬件错误的排查之道》的阅读笔记。这本书的主旨，是介绍如何修复bug：找出bug发生的缘由、并给出修复方案。

调试bug的九个规则列举以下，建议将这个清单打印出来，摆放在工做时候能看到的地方。

调试规则

接下来一次看下每一个规则的核心理念，从名字上来看，每一个规则看起来都比较明显（PS：因为翻译的问题，有些词可能没那么容易理解），可是理解这些规则和应用这些规则中间仍是差了不少距离的。

规则1：理解系统

你必须掌握系统的工做原理以及它是如何设计的，在某些状况下还要知道为何这样设计。若是你没有理解系统中的某个部分，那么这一般是出问题的地方。（这不只仅是墨菲定律的问题，若是你不能理解你所设计的系统，你的工做可能会变得一团糟）。

如何理解系统呢？

• 阅读手册
• 逐字逐句阅读手册，仔细理解每一个细节
• 知道什么是正常的，知道什么是正常的能够帮助你注意到什么是不正常的
• 知道工做流程，要理解业务，要讲系统的工做过程对应到具体要解决的现实问题
• 选择合适的工具，选择合适的辅助（监控、插桩）工具能够帮你理解系统
• 查阅细节，经验有时候会骗人，记忆有时候会出错

规则2：制造失败

这一点比较容易理解，就是问题复现，在平常工做中，你在排查一个问题的过程当中，最重要的一步就是复现问题——能复现的问题都能解决。

这里有几个要点须要注意：

• 引起失败，而不要模拟失败，不要尝试用不一样的方式去模拟问题，而要模拟和构建引起bug发生的条件
• debug的动做，不要影响错误的发生方式，能够影响错误的发生频率
• 从头开始，须要有一个正常的状态到不正常的状态的过程，从开始正常的状态开始观察，直到问题发生；
• 终极方案，控制变量法，将可能引起错误的因素依次排除；排除全部可能的缘由后，剩下那个答案，不管多么难以想象，都是事实。

规则3：不要想，而要看

亲眼看到底层的失败是很是重要的，若是你猜想失败是如何发生的，那经常会修复一些根本不是bug的问题。

在软件世界里，观察意味着设置断点、添加调试语句、监视程序值以及检查内存；在医学领域，须要测试血样和进行X光透视。

对细节的观察应该到什么程度合适呢？简单的答案是：一直观察，直到把问题的缘由锁定在几种可能以内。

在系统设计的时候，就要考虑到未来调试、排查问题的状况，将日志视为系统设计的一部分—打印一些关键日志，或者设计一些打开日志的开关，以便在生产环境针对某个case进行调试。

平常生活中有不少插桩的case：

• 体温计测量体温
• 自行车轮胎漏气时，都是将轮胎打满气，而后放在水里检查哪里漏气
• 自然气中加入了臭鸡蛋的气味

规则4：分而治之

反复将问题分红好的一半和坏的一半，而后缩小搜索范围，而后进一步研究有问题的那一半链路。

规则5：一次只改一个地方

初中就学过的控制变量法。
在修改bug时候，若是某个改动没有修复bug，就应该当即把它改回来。

规则6： 保持审计跟踪

记下你的每步操做、顺序和结果；
魔鬼藏在细节中；
将一些事情关联起来思考；
好记性不如烂笔头；

规则7：检查插头

一些显而易见的假设多是错误的；是否是运行了正确的代码？是否是打了正确的包？插头是否是掉了？从一些最基本的问题开始确认，不少时候问题就出在这里。对本身使用的工具进行测试，由于工具也是一种软件，难保不会出问题。

规则8：得到全新观点

“要想从新理清一个案子的头绪，最好的方法就是把它讲给别人听。” ——福尔摩斯，《银色马》

向别人解释问题的过程，会让你对问题进行从新的梳理和理解，这时候可能发现以前没有发现的问题。

bug发生了，以除掉bug为自豪，而不是非得以本身除掉bug才自豪。

无论你是跟什么人求助，或者须要别人什么样的帮助（征求意见、获取专业知识、听取经验），在向别人描述问题的时候，必定要记住一件事——报告症状、而不是讲你的理论；另外，有些症状你可能不是十分肯定，也能够描述出来。

规则9：若是你不修复bug，它将依然存在

“当危险已经离你很近时，拒绝认可它并非勇敢的表现，而是愚蠢。” ——福尔摩斯，《最后一案》

若是你不修复bug，它不会自动消失。按照前面的规则解决问题后，要进行一次回归验证，确保已经修复问题，而且没有引入新的问题。

个人感想

这本书里的不少案例都是是硬件相关的，对于软件开发工程师来讲不太熟悉，不过在阅读的过程当中，建议能够想一想本身在工做中排查问题的场景，是否是按照必定的章法去排查的？有没有从最基本的假设开始确认？有没有查阅文档？有没有关注本次变动的内容？有没有按照二分法进行排除？

做为软件开发工程师，在实际工做中不多有机会从0开始构建一个系统，更常见的状况是接手维护一个已经运行了几年、经历了几代的系统。写代码只是工做中的一部分，还有不少其余的事情须要作：修复bug、需求评审、系分评审、项目排期等等。

修复bug（解决问题）的能力，是软件工程师的核心竞争力之一。在最开始的工做中，有时候会羡慕老司机的“直觉”——看到一个错误日志，就大概知道是哪里有问题，后来本身查问题查得多了以后，本身也get到了这种“直觉”，也理解了——这不是直觉，这是已经被实践验证过不少次的经验，即便这样，我也会告诫本身——不能彻底依赖这种经验，经验有助于缩小待验证的范围，仍是须要事实（重现问题）去证明前面的猜想。

---

本号专一于后端技术、JVM问题排查和优化、Java面试题、我的成长和自我管理等主题，为读者提供一线开发者的工做和成长经验，期待你能在这里有所收获。