改了三处代码，问题消失了。哪处改对了？不知道。下次同样的问题再冒出来，还是得碰运气。
这是调试中最常见的状态：不是修不好，而是修好了也说不清为什么。
David Agans 做了二十年硬件和嵌入式调试，他发现效率差距不在经验和工具上。老手和新手的区别，是老手有一组不允许自己违反的规则。Agans 把这些规则提炼成九条。每条对应一种典型的调试坏习惯。
别猜，去看
调试效率最大的杀手是猜测。"我觉得可能是这里的问题"——然后改了，没验证就继续往下。
Agans 把"停下来，去观察实际发生了什么"列为核心规则。不是因为观察多高级，而是人在压力下本能地跳过它。截止日期在后面催，老板在旁边站，你的第一反应是赶紧改点什么——这恰恰是调试效率最低的动作。
"别猜了，去看"不是态度建议。它是一个可操作的检查点：此刻你正在看数据，还是在编故事？
一次只改一个
改了两处，问题没了。两处都需要吗？不知道。改了两处，问题还在。退回去的时候发现你忘了第一处改了什么。
Agans 反复强调这条，因为它违反人的直觉。你同时看到三个可疑的地方，手痒要一起改掉。但一次改多处，你丧失的是因果关系——从此每一步的判断都建在沙子上。
这条规则的执行成本很低。难的不是做不到，是忍不住。
理解系统不是加分项
遇到问题先翻代码，翻着翻着发现自己不知道这个模块的数据流怎么走。
"理解系统"是九条规则的第一条。不是因为它最花时间，而是它决定了后面所有判断的质量。你不理解系统，分而治之的切面选错，改一个变量的时候影响面判断不了，保留日志的时候不知道该看哪几列。
Agans 不是要你通读全部源码。他要的是：你知道信号从哪来、到哪去、中间经过什么。这三件事搞不清楚就开始改，后面全是浪费。
规则跨域有效
九条规则不挑语言、不挑平台。Agans 自己的案例从打印机电路板到嵌入式固件到桌面软件，跨度很大。
这和大多数调试类书不一样。多数调试书教工具——GDB 怎么用、Chrome DevTools 怎么断点、Wireshark 怎么抓包。工具确实有用，但换一个技术栈工具就失效了。
九条规则不绑定工具。"让它出错"在前端是写一个稳定复现的 test case，在硬件是搭一个能反复触发故障的测试台。规则一样，手段跟着环境变。
调试是可以练的技能
调试常被当成"遇到 bug 时的临场反应"。Agans 认为调试是工程技能，和写代码、做设计一样需要训练。
九条规则给出的就是训练支架。你不需要天赋异禀，只需要每次调试时对照规则跑一遍：我理解系统了吗？我能稳定复现吗？我在看数据还是在猜？我一次改了几个变量？
做到这些，调试效率的下限就有了保障。