文章目录
调试概述
-
调试是确定错误根本原因并纠正此错误的过程。同测试不同,后者是检测错误的过程,在一些项目中,调试可能占到整个开发周期的50%。对很多程序员来说,调试是程序设计中最为困难的部分。
-
调试原本不应该成为最难解决的问题,如果严格按照本书的建议,你几乎没有什么错误需要调试,你所面对的绝大数问题将都是一些微小的疏忽和拼写错误,这些很容易通过阅读代码列表或在调试器中单步跟踪来发现,针对剩下的一些难于解决的bug,本章将为你介绍一些调试手段,这些手段比通常的一些方法为你节省更多精力。
-
本书的上下文中,为保持术语的精确性,代码中的错误都称为“errors”(错误)、“defects”(缺陷)或“fault”(失误)
调试在软件质量中扮演的角色
- 同测试一样,调试本身并不是改进代码质量的方法,而是诊断代码缺陷的一种方法。软件的质量必须从开始逐步建立:开发高质量软件产品的最佳途径是精确的描述需求,完善设计,并使用高质量的代码编写规范。调试只是迫不得已采用的手段。
调试效率的巨大差异
为什么还要讨论调试?难道还有人不知道怎么调试么?的确如此,并不是每个人都知道怎么调试。一项研究表明,针对同样一组缺子,经验丰富的程序员找出缺陷所用的时间大约只是缺乏经验的程序员们的1/20。且一些程序员能够找出更多的缺陷,且能更为准确地对这些缺陷进行修改。下是一项经典调査的结果:展示了一组具备四年以上工作经验的程序员,调试带有12个缺陷的程序时的效率。

对于那三位精于调试的程序员来说,他们发现缺陷的速度是那些在这方面表现拙劣的程序员们的三倍,而所引入的缺陷仅仅是后者的2/5。最优秀的程序员在发现所有缺陷并进行改正的同时没有引入任何新的缺陷。而最差的程序员漏掉了12个缺陷中的4个,并且在改正所发现的8个缺陷的同时引入了11个新的缺陷。
除了让我们深入了解调试效率的巨大差异之外,这项研究还印证了软件质量的普遍性原则:提高软件质量能够减少开发成本。最好的程序员能够找出最多的错误,最快的找出错误,并且往往能够正确改正错误。不需要硬着头皮在质量成本和开发周期之间做出选择一一鱼和熊掌尽可能兼得。
让你有收获的缺陷
代码里面有缺陷意味中什么?如果你希望程序中里面一个缺陷(defect)也没有,那意味着你还没有完全理解程序的功能。
- 理解你正在编写的程序
你所面对的程序一定有一些东西需要你去了解,因为如果你确实已经透彻地理解,这个程序不应该有问题,你应该早就纠正了这些缺陷。 - 明确你犯了哪种类型的错误
一旦你发现了错误,请问问自己为什么会犯这样的错误,如何才能更快的发现这个错误?如何才能预防此类错误的发生?代码里面还有类似的错误?能在这些错误造成麻烦之前改正它们? - 从代码阅读者的角度去分析代码质量
代码易读?怎么样才能更好?用你的结论重构你现在的代码,并让自己下次编写的代码更好。 - 审视自己解决问题的办法
你自己解决调试问题时用到的方法让你感到自信?你的方法管用?你能够很快地发现缺陷?或者正是你的方法导致调试工作成效很差?调试过程中你有痛苦和挫败感?你是在胡乱猜测?如果你注意审视自己的调试方法,你或许就不会耗费那么多时间,花点时间来分析并改进你的调试方法,可能就是减少程序开发时间的最有效方法。 - 审视自己修正缺陷的方法
还需要关注自己如何修正缺陷,是否使用了goto这样的绷带或对一些处理特殊情况进行简单包扎(或许是最容易的修改方式)从而仅仅是治标而不治本?还是从系统角度进行修正,通过精确的分析对问题的根本原因对症下药尼?
想想所有这些,调试其实是一片极其富饶的土地,孕育着进步的种子。这边土地也是所有软件构建之路所交织的地方:可靠性、设计、软件质量、凡是想到的无所不包。编写优秀的代码所得到的回报,如果能精于此道,甚至无须频繁调试。
一种效率低下的调试方法
不幸的是,学院和大学的编程课程中几乎没有关于调试的内容。如果你是在校里学习编程的,那么你可能已经听过关于调试的几节课。尽管我受到了极好的计算机科学教育,所获得的调试建议也仅仅是“在程序中加上 print语句来找出缺陷”。这并不够。如果其他程序员在这方面所获得的教育经历同我相似,那么有很多程序员都将不得不彻底改变自己对调试概念的理解。这是多么大的浪费

最低0.47元/天 解锁文章
1万+

被折叠的 条评论
为什么被折叠?



