找出并修好出错的地方：调试

它告诉你停在哪里

程序一出岔，
不是悄悄地死掉，而是停在某一处。
然后用手指着：「这儿，这一行。」
那一指，就是最值钱的第一条线索。
报错，先告诉你「在哪里」停下的。

点运行。步骤一个个亮起，到出岔的地方就停住。

停在哪儿，一眼就看到了。
接着，那地方会冒出一行红字。
很多人一看到它，就先慌了。
可它其实是我们这边的。因为……

红字不是责备，是提示

那行红字，不是在骂我们。
而是写着「它没看懂什么」的一张便条。
通常装着两样：地方(在哪)和种类(是什么)。
像「这不是数字」「没有那个名字」。
只要学会沉住气去读，就解了一半。

点点信息的各块。「在哪」和「是什么」会分开亮出来。

把信息拆成「在哪」和「是什么」来读，
刚才吓人的字，忽然就显得亲切了。
可它指的地方，未必就是真正的原因。
要是程序很长，怎么快快缩小原因呢？

把范围对半缩小

不知道漏洞在哪儿的时候，
别从头全读，先看中间。
到这儿都好端端的吗？那漏洞在后半。
不是的话，就在前半。再对半。
这「对半缩小」，再长的代码也能很快揪出元凶。

点「查看中间」。按好/坏，范围就减一半。

按几下，范围就缩到一处了吧？
没全读，也精准点出了元凶。
找到原因的地方了，接下来该修了。
可修的时候，有一个陷阱。

一次只改一处再确认

看见个像原因的，就别一下子全动。
同时改五个地方，
就算好了，也分不清是哪一处修好的。
冒出新问题，也不知道怪谁。
所以只改一处，运行一下，再细看。

只改一个候选再「确认」。改多了，是什么修好的就糊了。

一处处地改，真正的原因就清清楚楚了。
准确知道了元凶，也修好了。
那么就完了吗？还差一步。
「好像修好了」和「修好了」，是两回事。

修好后，一定再跑一遍确认

光以为修好了，还不算完。
再运行一遍，亲眼看着它一路通过到底，才算完。
顺带，也看看原本好好的别处有没有被弄坏。
这「修好再确认」的一圈，
就是瞎猜和真正修好之间的那条线。

点「再跑一遍」。修好的程序一路绿到底地通过。

如今我们既会建造(第1~13课)，
也会在出岔时找出并修好(第14课)。
可我们写下的这些字，
是怎么变成真机器去跑的东西的呢？
下一课，我们沿着这段文字变成机器之事的路，走一走。