程序设计实践(排错）

 

作为程序员，对代码排错应该绝不陌生。从当初的“ hello，world!”到后来的大规模应用，排错一直陪伴着我们。很早的时候，照着书敲程序，编译的时候却出来一大堆错误，手足无措，百思不得其解，最后不了了之。错了就错了吧，扔那儿不管了。偶尔也会认为这是工具（编译器）的错误，或者书上的例子错了。现在回想起来，都是自己的错误罢！奇迹总是很少的，不然也不会称之为奇迹，程序出了问题，多半还是自己的错误，老老实实去查自己的代码，不要推到其他地方。

代码排错是一种艺术，很需要技巧和经验。光错误识别、错误定位，就需要很强的功底。怎么排错呢？

一、做好设计，尽量避免错误。程序出了问题，多半是由于设计不好。写程序的时候，我们常不愿意做详细设计，即使是详细设计，也做得很概要。这一方面是项目管理上的问题，项目进度安排不合理，导致过早写代码，或者需求不明确，不能深入设计；一方面是程序员不愿意有详细设计，写文档是程序员最不愿意做的事情，认为没有成就感，另外程序员不愿意有太多约束，设计过于详细，他们觉得没有发挥的空间，感觉成了苦力。这些问题都是存在的。但是我们也发现，程序的错误，多半是由于设计不够造成的。错误的设计，会导致成个项目的崩溃，设计不够却会带来无穷无尽的小 Bug。

比较好的设计，应该有设计完善的界面，对于模块和模块之间的交互，一定要详细，这样才能确定好各模块的数据交互，确定各模块的责任，尤其是资源管理的责任。数据交流方式不明确，常导致更改返回类型或参数个数，模块责任不明，常导致代码重复，于是 copy,paste；资源管理不明常导致数据访问混乱。这些都是产生错误的根源。对于单个模块，要设计精良的状态图，不明确模块状态变迁会导致函数内部逻辑混乱，更是错误之源。

二、要耐心分析错误现象，确定错误类型。如果设计良好，产生的错误可能由于写程序的粗心，这种错误比较简单；否则很可能是程序内部逻辑不合理。发现错误以后，我们应该首先冷静下来，分析可能错在什么地方，是由什么原因引起的，如果是这个错误，还会涉及到那些地方？都考虑全面了，才对程序进行更改。有些程序员喜欢单步跟踪程序，观察执行过程以定位错误。这种方法对于逻辑简单、规模小的程序比较适用，对于大规模的开发就不合适。如果程序运行环境很复杂，如果输入复杂，等等。我们很难对这样的程序进行调试，太费时间。耐心、冷静地分析代码会是个很好的选择。有些程序员喜欢发现错误后，立刻就更改，然后再运行，观察。这也是不可取的。改的次数太多，你可能就忘了错误原来的模样，另外非常浪费时间。

三、多写打印语句。打印出程序的核心数据比单步调试观察数据效果好多了。这些代码停留在程序里，可以多次利用。写一些错误输出函数是个不错的选择。如 print_mess( const char* func_name, int line, const char* mess )函数可以告诉你程序的哪一行出了什么问题。对于一些复杂的数据结构，更是可以写一个打印函数，java的toString方法很是不错。

四、设计好的测试用例。好的测试用例依赖于程序员对程序内部的理解程序。如果清楚地知道程序内部逻辑，感觉到程序会在什么条件下出问题，出什么样的问题，测试就变得简单。开始测试时使用的是正确的输入，观察程序在正常的环境下能否运行正确，然后测试边界值，再测试非法输入。当出了问题，要结合程序分析测试用例，以尽量缩小用例的规模。以前在测试一词法分析器时，输入 8万多行的标准头文件，测试过程中遇到的死循环错误。不能够确定什么样的输入使程序进入了死循环。最后让程序每分析一个Token就输出一次，然后进行比较，这样很容易地缩小了测试用例。

五、没有办法的时候，耐心地使用排错工具吧。

排错是一种艺术，但更基于对程序的了解和经验的积累。良好的设计比什么都重要，多多动脑比多多动手重要，耐心和细致更是必须 !

 书中测试的原则有：

1、寻找熟悉的模式；

2、检查最近的改动；

3、不要两次犯同样的错误；

4、现在排除错误，而不是以后；

5、取得栈轨迹；

6、把你的代码解释给其他人；

7、把错误弄成重现的；

8、    分而治之；

9、    研究错误的计数特性；

10、              显示输出，使搜索局部化；

11、              写自检测代码；

12、              写纪录文件；

13、              设法用统计的方法分析复杂的数据结构，并图形化显示；

14、              写一些简单的程序去检测你的假定；