硬件调试和软件调试的一点点微小的思路1

无论是硬件调试还是软件调试(这里说的调试是调试bug，不是调试参数)．

调试的核心的目标只有一个，那就是尽可能精确地锁定到决定性的错误因素．

而核心的手段也只有一个，那就是分解问题．

首先考察一个问题：在什么情况下，我们认为硬件/软件存在bug？

一般我们会觉得，当系统呈现的实际输出（灯的亮灭、电机的转与不转，转快转慢、飞机的平衡与不平衡）和我们的设想输出不一致的时候，我们会觉得有bug．

拿编译过程举例，编译系统的实际输出（有error）和设想的输出（没有error）不一致，我们就认为我们写的代码有语法bug，编译不通过．拿实际功能举例子，虽然编译通过了，但是系统的实际输出（灯不亮），和设想的输出（灯亮）不一致，我们就认为出现了语法之外的错误．

抽象点说，是人对想要认识的对象（硬件/软件系统）的主观认识，和想要认识的对象的客观现实相违背时，我们就会说，"啊，有bug了"．

系统有bug的状态，是主客观相违背的状态，而没bug的状态，很容易就可以知道是主客观相统一的状态．

调试的过程面临的根本矛盾，就是对系统的主观认识和系统客观现实之间的矛盾．

要解决这个根本矛盾，我们的方法是抓住这个根本矛盾中的主要矛盾，就是：决定性的错误因素．正如开头所说，调试的核心的目标只有一个，那就是尽可能精确地锁定到决定性的错误因素．

就比如说，有三个同学小蔡，小许和小昆，他们三个人都遇到了灯不亮的问题，而经过了不懈地努力，他们终于发现，小蔡同学的灯不亮，是因为他电源断了；小许同学的灯不亮，是因为灯丝断了；小昆同学的灯不亮，是因为他开关坏了．

在这个例子里面，灯不亮是系统bug的根本矛盾，而电源断了、灯丝断了、开关坏了就是系统bug的主要矛盾，也就是决定性的错误因素．

我们可以很容易地发现，他们三个同学的遇到的根本矛盾相同，而主要矛盾却各不同．

很显然，在这个例子里，当三个同学发现了他们的系统bug里的决定性错误因素时，他们也就可以很轻松地解决bug（换电源、换灯泡、换开关）．

但如果他们没有发现决定性的错误因素时，他们就很难解决bug（小蔡电源坏了却换了灯泡、小许灯泡坏了却换了开关、小昆开关坏了却换了电源）．这看起来很傻，但根据我的一些已有的一点点微小的观察，发现有很多同学像没有找到决定性的错误因素的小蔡同学，小许同学，小昆同学一样，在做电源坏了却换灯泡的工作．

还经常会出现电源坏了却换灯泡，发现不好使又去换开关，发现不对劲又去换灯泡的死循环，这就叫做不会调试．

to be continue．．．．．．