《.NET 应用程序调试》阅读笔记

 

摘抄几段：

美国国家航空航天局就因为在设计阶段溜进了一个Bug而损失了一个火星航天探测器。

GPS软件中的电池更换所产生的一个程序错误导致了一枚炸弹偏离其原定目标而砸向了美国特种部队士兵。

微软发布了一个程序补丁以挽救之前一个程序补丁造成的微软IE 6上的巨大缓冲区溢位漏洞。

尽管Bug开始逐渐地受到应有的关注，但距离我们形成一种高度重视Bug，并不再将其视为开发过程中不可避免的小问题的开发氛围，我们还有很长的路要走。

即便你有计算机专业的学位，我打赌在你的大学里从没有一门课程是专门针对调试过程的。除了一些诸如设计某些根本没有人用的语言的自动程序校验之类的神秘兮兮的课程，或者为盲目乐观的超大平行进程计算机开发的调试器之外，对应用于商业软件的调试科学似乎从来都不大受教育机构的欢迎。

在软件开发过程中，调试是唯一能让软件工程师们踢东西、尖叫甚至摔电脑的部分。这种程度的情绪爆发对于程序员这个一般少言寡语、沉默内向的人群来说是很不寻常的。调试也是在软件开发过程中能导致你通宵达旦工作的原因之一。

对于Bug，你必须要高度重视，因为它们最终会让你付出高昂的代价。

在你开始进行调试前，你得先弄清Bug的定义。我对Bug的定义是“使用户头疼的任何问题”。我把Bug归为如下几类：

n  崩溃与挂起。

n  性能与可伸缩性差。

n  错误的结果。

n  安全漏洞。

n  用户界面不一致。

n  未达到用户的期望。

 

Bug产生的原因大致可以分为如下几类：

n  过短的或不可能的交货期限。

n  先编码、后思考的开发方法。

n  需求理解错误。

n  工程师的知识空白或所受培训不当。

n  缺乏质量意识。

 

来源：

http://book.csdn.net/bookfiles/885/