把问题缩小，答案才会清楚

遇到一个复杂问题时，最容易做的事是立刻修改代码。更有用的第一步，却可能是先停下来，把问题描述清楚。

把现象和猜测分开

“点击以后没有反应”是现象；“事件监听没有注册”是猜测。把两者写在不同的位置，能避免调查过早地沿着某个方向走下去。

一份有用的问题记录，可以只包含三件事：做了什么、原本期待什么、实际发生了什么。再补上输入与运行环境，就有了一个可以讨论的起点。

找到最小的复现过程

尝试减少输入，关掉无关的功能，缩短操作步骤。每去掉一个仍不影响复现的条件，问题的边界就更清楚一点。

假如一份很大的文本会导致显示异常，可以先截取其中一小段，再继续缩小。最终留下的也许只是一行很长的文字、一个特殊字符，或者某种换行组合。

好的复现步骤，是给问题画出一条足够窄的边界。

一次只改变一个条件

同时修改多个地方，即使问题消失了，也很难知道是哪一个改动起了作用。先写下当前假设，再选择一个能区分不同原因的检查方法，让每一步都提供新的信息。

修复之后，回到最初的复现过程，再检查几个相邻情况：空输入、第一项、最后一项，以及连续重复操作。它们常常能帮助发现边界处遗漏的行为。

留下可以再次使用的解释

调试的终点不只是“现在能用了”。记录触发条件、原因和修复方式，下一次遇到相似现象时，就不必从头猜起。把复杂问题变小，也是在给未来的自己留一条清楚的路。