- 崭新磁盘为何用过一次就不好使？
- 为何屏幕上的所有文本突然不见？
- 为何 QA 总能搞出乱码问题但开发就是测不出来？
调试（Debug）可能是计算机工程中最被忽视的领域——算法，语言和架构的书籍一抓一大把，但有关调试的书籍几乎没有——你可以在 Code Complete，The Practice of Programming，Writing Solid Code 这些上古程序设计实践书籍中找到一些调试有关的内容。但讲调试的书籍，我只知道 调试九法（英文书名 Debugging: 9 Indispensable Rules 以下简称 D9）这一本。
仔细想想，这并不合理——调试应该是软件工程中最耗时的过程，为啥没人写这方面的书呢？我觉得：
- 调试是一线开发技能，但书籍作者往往可能已经远离一线开发，早就忘了咋调试
- 调试属于脏活累活，既没有算法那么科学向，也没有架构高大上
D9 应该是唯一一本讲调试的书——它通过各种案例（五花八门，既有软件又有硬件，还有吸尘器热水器）讲述九个调试基本规则：
- 理解系统
- 制造失败
- 不要想，而要看
- 分而治之
- 一次只改一个地方
- 保持审计跟踪
- 检查插头
- 获得全新观点
- 如果不修复 bug，它将依然存在
以上九条规则看起来平平无奇，但经过八年实践（我在工作之前就已经读过 D9），我可以确定：所有我见过的大神都在践行这九条规则，同时，所有我见过的菜鸡都在违背这些规则。
如果查找一个bug花费了大量时间，那么原因可能是忽略了某个最基本的、最重要的规则，一旦应用了那条规则，很快就会找到问题。
擅于快速调试的人已经深刻理解并应用了这些规则，而那些很难理解或使用这些规则的人则很难找到bug。
继续阅读[书评] Debugging: 9 Indispensable Rules – 调试九法