了解代码调试，出现bug和错误不慌了

代码调试

调试的概念

程序在进行发布投入实际应用前，我们要先使用一些办法来进行测试，就称为调试，也叫改bug。

对于调试的理解

我们知道在计算机里，代码的微观运行过程，是三步走

1. 取代码
2. 译代码(分析代码)
3. 执行代码

那我们宏观人也有自己调试代码的步骤：

1. 写代码
2. 报错，解决的常用办法：找原因和怎么解决，想办法(百度)，修改，再运行
3. 错误分析(先要做到的是发现问题，先研究问题本身，有利于之后的解决)这里书上补充的好：就是遇到问题时，我们去debug，可以动态地帮助我们寻找原因。比如可以有哪些切入口？有哪些重点重点(也就是思路)？
4. • 报错，代码直接运行不了、404、或者没变，这种类型的错误，可以归纳为链接错误。
   • 如果代码能运行，但与想要的结果有差别，或者哪个结果不是自己想要的，那就是逻辑问题，逻辑错误。要多次检查流程控制的设计了。
5. 解决问题，假设几个模拟数据去运行，且把输出结果与手工处理的正确结果相比较。就是通过对比来找原因，研究错误。然后解决它。发现问题，总比解决要复制一些。

心态建设（原则经验）

大家在写代码的时候可能经常会遇到，一下子报很多很多错误让人猝不及防的情况吧。

然后再进行代码调试的时候，时常会遇到错误，要在心里告诉自己错误是很正常的。耐心些慢慢来。
遇到错误不要慌，我们有解决的办法。

一般有卸载重装。
但是有些方法可以帮助我们找到问题的线索，提高修改问题的效率。
比如输出语句，把变量试着输出，看看里面的值；
比如debug动态观测变量的变化与传值。
还有一些配置问题、系统问题，我们可以通过打开服务，或者找到文件目录，试着找到问题所在地。
配置问题一般是路径问题，导致服务不能打开。
或者两个程序冲突，占有着同一个端口。还有网络的问题，防火墙的问题。
这就可以去那些设置文件里，配置和更改。具体如何实现，可以去百度搜一下。

---

我们遇到了问题，首先要做的就是好好研究这个问题本身，去观察和发现问题的一些提示和线索。就是一切都要从记录问题开始，先记录，先观察分析，然后我们才能好好地把它解决。
在心里认知到，问题=现象=困难。这些都是同一个意思。一切的科学，都是从发现问题(现象)、提出问题、记录问题后，才研究问题、最后得出结论的。
最最后才是顺利解决这个问题，或者解释这个现象。任何问题的解决都不能违背这个逻辑的，规范一点，尽善尽美一点。

---

所以我们改bug，也要先研究好这个问题。我们把能够观察、发现、考虑到的线索，列举好，记录好，然后假设一个个的试着看看。

我们要先清楚这是一个什么问题，试着猜测或者假想什么原因，要能够很清楚的描述好这个问题，抓住问题的关键点。我们把问题记录好之后，再研究好这个问题，分析好这个问题，理解这个问题。
我们最后才能快准狠地找到解决方案好这些问题。不然就会像无头苍蝇一样，试了很多方法，结果问题还是没有被解决，效率地下，费白功夫。

而且，我们每每遇到一个问题，并且成功解决之后，我们一定要好好记录一下，反思总结一下，整理成bug库。这样以后遇到类似的问题就可以快速解决。整理，总结一下，它是什么问题？有什么表现线索、预兆、现象？最关键的是哪个字，是属于什么地方的问题？最后我们怎么准确描述这个问题？
最后，也可以去看看别人怎么解决，寻求帮助。最后问题成功解决，我们要把过程，和以及怎么解决的都要记录下来，整理成库。

调试bug的一些具体实用的方法

1.打印输出大法

在程序里插入打印语句，试着打印一下，输出一下。优点：能够显示程序的动态过程。缺点：可能打印了大量无关信息，效率低，发现错误有点听天由命。

2.运行部分代码

有时候出现错误，我们不需要运行全部的代码，而是可以抽出一部分需要检查的代码，选择性的运行检查。比如用到测试类，写测试类。

3.借助调试工具，比如IDE自带的DeBug工具

下断电，动态分析变量的变化或者页面跳转值的变化，这些工具能够帮助我们去分析代码的动态行为。

遇到问题思维要转化

我们解决问题往往非常简单，难的重要的是，要发现问题的所在。
我们的思维，要改变一下:

遇到问题不是“啊！遇到问题了。怎么办？”，别被一板一板的红色报错吓到。
遇到问题的时候，因该是多问问自己——“这个问题是什么？问题它出现在哪里？是什么原因导致的这个问题？这个问题有那些现象、性质、表现、特点、征兆、线索？以及这个问题最后该怎么解决？”这些是遇到问题该有的思维。

方法拓展：

1.回溯法排错

就是看它报的什么错，确定最先发现错误症状的地方，有些编辑器，你点击红色报错，它会告诉你，错误出现的地方的。根据错误提示，我们根据它的流程控制的逻辑逆推，发现错误发生地。

2.归纳法排错

归纳法是一种系统化的思考方法，是从个别推断全体的方法，是从问题本身的线索、表现、现象、特点、症状、征兆出发。通过分析特点、线索、思考点，思路之间的关系找出故障。

2.1收集相关数据

收集相关数据，就是利用测试案例（测试类），观测它报了那些错，或者与结果有偏差，以及在什么情况下出现的错误信息。

2.2组织整理数据

组织数据，整理一下，列举出那些错误信息。看看什么条件下出现错误，什么条件下又不出现错误。

2.3试着假设

根据所学的知识，和所搜索到的关键资料，试着假设，给这些错误做一些假设解释。有一个或多个的假设。如果你无法做出假设，那就要多写测试用例，
多测试，多得到一些报错，或不满足需求的错误信息。从而帮助自己做出假设。

2.4证明假设

证明假设。假设不等于事实，证明假设的重要性是非常必要的。如果用不经证明的假设去解释、排错;往往只能消除错误的征兆或者消除一部分错误。当然，错误是永远存在的，因为客户的需求会有变化和不同。
那么证明证明假设？证明假设的方法：
就是利用自己的假设解释所有的测试结果，如果能圆满的解释一切现象，则假设成立。不然要么就是假设不成立，不完备，要么是多个错误同时存在。

3.演绎排错法

假设可能的原因，用已经有的数据，和一些经验排除不正确的假设，精化并证明余下的假设。
好比程序突然报错，有的人就总是怀疑可能是底层基层的问题，或者基础构建的问题，有的甚至还怀疑到了硬件设备上了。。。其实就是没有对不正确的假设，做一个排除。
再比如一般程序运行不了，可能就是代码写错，或者一个标点没写，或者一个单词被落下了一个字母。或者多一个中文的空格。
我们可以设置一些测试，去排除一下。或者改一个写法，再创一个类去对比排除。一般运行不了，可能就是服务冲突呀、其他同名服务没有关、或者和某个应用的端口名相同，端口冲突呀、或者路径问题—有相同的文件名和配置路径环境，比如java和Oracle里Java的冲突，导致Java测试不能出结果。
还有就是版本的匹配问题，有些东西的显示要更高的版本。还有防火墙。MIME的映射关系，一般就是服务器和浏览器，文件在浏览器里打开的映射。其实映射就是判断和复制。

4.对分查找法（用来查找错误位置的方法）

如果知道每个变量在程序若干个关键点上的正确值，则可以在程序中的关键点附近通过输入或赋值语句“注入”这些变量的正确值。
然后检查程序的输出。如果输出的结果是正确的，则表示错误发生在前半部分，否则不妨认为错误在后半部分。
这样反复进行多次，就能逐渐逼近错误的位置。

编辑时注意分类（分类编辑）

静态调试

有两种方法：

• 1.输出寄存器的内容：测试出问题，设法保留现场信息报错。不过输出的是程序的静止状态，效率低。
  那些一错，错一板的，其实很多都是链接问题。很多错误是一个地方错而连带出来的错误。就是一步错步步错。所以要找到最关键报错的那一句话，和只看那些是自己写的代码。就可以避免被吓到。
• 2.为获得关键变量的动态值，在程序中插入打印语句。会输出大量信息。适合简单的块。而且可能打乱时序。

动态调试

就是debug，利用调试工具。下断点。一步一步执行，看值的变化。断电可以下在条件分支，页面传值，方法传参处。或者下在变量赋值语句的地方。比如js可以用FireBug。