调试也叫找bug，bug就是小虫子的意思。那找错误为什么叫找小虫子呢？我们都知道计算机的部件一开始并不是现在的芯片，是从真空管开始的。那个时候的计算机体积大，运行效率低。结果都是0跟1打印出来的。有一次一位教授用计算机计算的时候发现计算结果一直没有对，但自己写的代码又找不到问题，最后他觉得是计算机哪里出了问题，于是就去找问题；结果是一只虫子飞到了机房，影响到了它的正常运算。把小虫子处理了之后就得到了正确的结果。于是大家都把寻找代码问题这个事情叫成是找bug，也就是找小虫子。当然现在我们也很少会被小虫子影响到代码的运行了，但这个概念一直延续了下来。
这次我们要说的就是这个调试了，现在我们的工具都是高度集成化的IDE，scratch就是少儿编程领域的佼佼者了。但是反而这个scratch的调试比较特殊，原因也是它很简单的编程方式造成的。高度的封装使得我们看不见脚本内部的执行过程，也就导致了我们在运行代码的时候只是看到了舞台上展示出来的结果跟我们想象的不一样，但是又不会有具体的信息打印出来。这也是有个中原因的，因为我们看到的bug都是逻辑层面的，而不是语法规则层面的。逻辑层面的bug通常是很难找的，就算是正常的开发我们使用的也是打印日志居多。看一下运行的过程中数据的变化，然后推测可能是哪个环节出现了问题，也就是说这种类型的bug计算机已经不能很明确的告诉我们了，它已经做了自己能做的，而且也算出了最后的结果，只是这个结果不是我们想要的，但是计算机是可以算出来的，所以它并不认为这是存在问题的。
而语法规则层面的问题是计算机在编译的时候就知道了的。我们都知道其实计算机运行的本质就是对0和1不断作出计算。那我们编写的代码也是一定不会是例外的，它们在运行的时候也会由解释器和编译器把我们的代码编译成计算机可以识别的二进制。语法规则层面的错误是计算机在生成二进制的时候就知道了的，所以会非常明确的告诉我们。当然了用scratch编程语法层面的错误我们是不可能去犯了，因为教授大佬们都已经给我们做了处理，避免了这类问题出现的可能性。
因此我们对scratch的调试就有了一个大的方向。那就是打印运行过程中的日志，同时也把数据打印出来，这样我们的列表就派上用场了。很多的时候我们只需要把数据存到列表中，然后查看一下列表中当前的数据，再跟之前的数据进行比较一下我们就大致可以推断出是哪里出了问题 。这是其他高级编程语言开发的时候也是经常用到的方法。也是最有效的方法了。
另外还有一种是排除法。编程对应的大部份是可穷举的算法，也就是说我们的代码执行的时候会进哪些分支我们是可以提前预测得到的。因此我们才有可能用如果...那么。。否则 等之类的积木块来进行运行规则的制定，然后写出对应的代码。我们的代码都是要连接在块中的时候才会去执行。如果不是那么也就不执行，所以我们可以把我们认为有问题的代码块先去了，然后看看执行的结果是不是正常的，这样多来几次排除法我们也就能知道存在问题的代码块了。
不同的代码块有不同的调试方法，一些代码块我们只要直接显示一下运行的结果就可以了。大家根据实际情况采取对应的策略。
