200604231319105.html

软件工程的红包书

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 最有效的发现和修复缺陷的方法是个人复查源程序清单。这种方法是负很难彻底清除程序中的缺陷，但事实证明，这是最快而且最有效的方法。</P>
<P><BR><STRONG>3、代码复查</STRONG></P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 代码复查就是研究源代码，并从中发现错误。代码复查更有效的原因是：在复查时看到的是问题本身而不是征兆。从头到尾复查代码时，考虑的是程序应该做什么。因此，当看到某些地方不正确时，就可以看到可能的问题是什么，并立即去验证代码。复查的缺点是：非常耗时，而且很难恰当的进行；复查时一种技能，当然可以通过学习和实践来提高。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 代码复查的第一步是了解自己引入的缺陷的种类，这是收集缺陷数据的主要原因。因为在下一个程序中引入的缺陷种类一般会与前面的基本类似，只要采用同样的软件开发方法，情况会一直如此。另一方面来说，当你有了技能和经验或改变了过程，缺陷的类型和数目会随之变化。但是到了一定程度后，改进就变得非常困难了。这是，就必须研究缺陷，这可以帮助你找到更好的发现和修复缺陷的方法。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 如何进行代码复查。代码复查的目标是在软件过程中尽可能早和尽可能多的发现缺陷，缺陷发现时间越少越好。采用表4.3描述的一个有序的检查方法，在编译之前进行代码复查，是完成目标最好的方法。</P>
<P><IMG src="20063614460103.jpg" tppabs="http://www.itisedu.com/manage/Upload/image/20063614460103.jpg" border=0></P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 编译之前进行复查。有几个原因说明应在编译之前进行代码复查：不论编译前或编译后，进行完整的代码复查的时间大约相同；不论编译前或编译后，对检查语法有效性的效果是一样的；先做复查将节省大量编译时间，若不做代码复查，一般要花12％～15％的开发时间进行编译，一旦使用代码复查后，编译时间可以缩短至3％或更少；编译程序后，代码一般复查很难彻底的进行； 经验证明，在编译阶段有大量的缺陷时，一般在测试阶段也有许多缺陷。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 建立个人代码复查检查表。如果想发现和改正程序中的每一个缺陷，就必须遵照一个精确的规程。检查表可以确保遵循这个规程，它包括一系列程式的步骤。按照检查表去作时，就知道如何进行代码复查。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 如果能够正确使用检查表，还能知道每个步骤发现了多少缺陷。这样就能测量出复查过程的效率，并进一步改进检查表。检查表包括了个人的经验。通过不断的使用和改进个人检查表，就可以帮助你用较少的时间发现这些缺陷。表4.4是一个C++程序代码复查表的范例。</P>
<P><IMG src="200636145839440.jpg" tppabs="http://www.itisedu.com/manage/Upload/image/200636145839440.jpg" border=0></P>
<P><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 定期更新检查表。随着时间的推移，检查表自然的要变大。但是，检查表的主要作用是帮助你把注意力集中在关键的方面。太大以后，你将失去重点。所以要定期复查缺陷数据，删除那些不能找到问题的表项。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 从个人检查表的方法可以认识到，每个工程师都有各自的特点，某个工程师的实践经验对别人不一定适用。因而要设计出适合自己的检查表，并定期的对它进行检查以保证检查表更有效。只要你在代码复查中还遗漏缺陷，就要不断寻找改进检查表的方法。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 进展是很缓慢的。最初，你发现缺陷的能力随着每次复查都有所提高。此后，提高将变得很困难。要坚持收集和分析缺陷数据，并坚持思考如何才能预防缺陷的产生或怎样更好的找到缺陷。只要坚持不断的做下去，就能在代码复查中不断进步，不断提高自己编写程序的质量。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 编码标准。编码标准是被广泛接受的、能够作为工作样板的编码实践集。良好的编码标准将有效地帮助您避免开发有潜在危险的代码，有助于预防缺陷。例如，可以在编码标准中列出那些应该避免使用的方法，规定号循环入口或在说明是初始化变量，避免不良的变量命名等。编码标准还能有效地统一和规范整体开发活动。当其他开发人员加入到项目中来时，他们能够很好地适应这一切。代码也将变得更规范更易维护。</P>
<P><IMG src="200636154743285.jpg" tppabs="http://www.itisedu.com/manage/Upload/image/200636154743285.jpg" border=0></P>
<P><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 其他种类的代码复查。在软件组织中，一种常用的方法是同行评审，就是几个工程师彼此复查程序。组织良好的同行评审一般会发现程序中50％～70％的缺陷。互查虽然需要很多时间，但是可以有效发现缺陷，因为工程师往往难于发现自己的设计错误。他们创作这个设计，直到程序应该完整什么，即使概念有瑕疵、作了错误的设计或实现假定，他们往往很难发现。检查这可以帮助他们克服这些问题。对一个大的项目，最佳检查策略是，先做个人代码复查再进行编译，然后在任何测试前进时行同行检查。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 细心工作是有回报的。当工程师觉得对自己开发的程序附有质量责任时，他就不会依赖于编译器或其他工具来发现缺陷。全面的代码复查要花费时间，但是他们节省出来的时间比花费的时间多得多，并能够生产出更好的产品。</P>
<P><STRONG>4、缺陷预测</STRONG></P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 引入缺陷是人类的正常现象，所有的工程师都会引入缺陷。因此所有的工程师都应该了解自己引入缺陷的类型和数据。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 在开发过程中，总是可再进行一轮测试或代码复查，决定是否这样做的唯一方法就是分析缺陷数据。通过分析历史数据，可以估计出程序中缺陷的个数。通过把当前项目的数据和估计数据相比较，就能大概知道正在开发的程序的质量情况。这样就能决定是否需要增加一些缺陷排除步骤。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 缺陷率的预测。当开发一个新的程序时，可能会觉得很难估计你将引入多少缺陷，理由是缺陷的个数因程序的不同而不同。缺陷个数不稳定是有以下几个原因造成的。首先使经验问题，个人的技能是在不断提高的。开始编程序时，要面临着很多以前没有碰到过的问题。往往不能确定有些过程和函数是如何执行的，可能是语言的结构不清楚或者可能会遇到新的编译器或编程环境的问题。这些问题都会引起开发时间和缺陷路的波动。有了经验后，你将逐渐克服这些问题，犯的错误就减少了。这既减少缺陷的总数又减少缺陷数目的波动。缺陷的减少起初是由于经验的增加和对语言熟练程度的提高。经过这最初的提高后，就需要收集和分析缺陷数据来进一步改进了。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 缺陷路波动的第二个原因是个体过程不稳定。当开始学习写程序时你也同时开始学习使用新的过程和方法。你的过程将随着实际的经验不断的发展，这就会引起完成不同程序任务的时间和引入缺陷的数据的波动。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 最后，缺陷本身也是这种变化的原因，引入的缺陷越多，修复这些缺陷所花时间就越长。修复缺陷所花的时间越长，引入新的缺陷的几率也就会增加。因此缺陷的修改时间变动幅度很大。所以，很难对一个引入很多缺陷的过程进行预测。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 随着开发过程的改进，过程会逐步稳定下来。这种稳定将提高缺陷预测的准确性。试验证明，如果在代码复查方面花了足够的时间，你的过程会迅速稳定下来。一旦你的过程相当稳定，缺陷也将容易预测。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 根据对最近的程序跟踪每千行引入和排除的缺陷数，就可估计出在将来的程序中可能引入和排除的缺陷数。</P>
<P>(选择自 treewith 的 Blog )</P>
<P></FONT>&nbsp;</P></div>
</body>
</html>