答复: 代码评审怎么做，做到什么程度合适？

不知道.看帖的人,有没有看过《代码大全》这本书.里面讲到的"评审"这一章还是非常不错滴.如果有兴趣.我这有电子文档.需要的找我。
下面贴出节选内容:

评审在软件质量保证中的地位

 评审质量和进度
评审一般包括两种类型：管理的和技术的，管理评审用于评估进度和建议纠正之中。它们
着眼于花费和计划。管理评审是重要的，但是不是本书讨论的主题。
技术评审也可用于评估进度，但是它要求技术进度是可评估的。这通常意味着以下二个问
题：（1）技术工作是否正在进行之中？（2）技术工作是否做得较好？以上问答是技术评审的副
产品。

 

 

检  查

 

检查是一种特殊类型的评审，它在错误检查中被证明是行之有效的，并且和测
一种相对较为经济的办法。检查方法由 Michael  Fagan 所发明，并在 IBM 应用了
Fagan 将其出版发行。虽然任何评审方法都包括阅读设计资料或代码，检查和走
观是不同的：
·  检查表将检查者的注意力集中在过去所遇到的问题的领域中
·  检查侧重于错误检查而不是纠错
·  评审者在检查之前应先举行预备会议，而他们最后得出的问题应是经过共
·  所有的参加者被分配以不同的任务
·  检查协调者并不是被检查产品一方的人
·  协调者在协调检查方面受过一定的训练
·  每次检查所得数据都被收集起来，以便反馈给今后的检查以提高检查质量
·  一般管理人员并不参加检查会议，而技术主管则有可能参加会议

 

检查概述
检查表可使检查员注意力集中在某一类错误上。由于检查过程有标准的检查表和标准的各
司其职的人员，它是一个有组织的过程。它也是一个自我优化过程，因为它使用有正规的反馈
循环以提高检查表质量、监控准备和检查速度。有了以上对过程的控制和优化，不管它怎样开
始的，检查很快就成为一种强有力的方法。软件工程学会（SEI）已经定义了用于度量软件开发
过程效率的技术标准。检查过程表明了何为最高水平。同时，检查过程应是有组织的、可重复
的，并能使用可度量反馈以提高检查质量。你同样可将本方法实际应用于本书所讨论过的任何
技术中。在开发过程中将这些思想归纳起来，那么简单地说，它们可使你所在机构向着最高质
量和生产率的层次进军。

 

其它评审方法

 

普查
普查是一种流行的评审方法。普查这个词定义并不严密，因为人们实际上可称任何类型的
评审方法为“普查”。
由于普查定义不严密，所以也就很难对其给出确切的定义。当然，普查包括二人或多人讨
论设计或代码这种情况。普查可能就像即席的随意探讨会一样不正式。有时它也可能像一个预
定的会议或送给管理者的总结报告一样正规。在某种意义上讲，“什么地方有两或三个人聚在一
起”，什么地方就存在普查。普查方法的支持者赞成使用这样一个宽松的定义。所以本文只打算
找出普查的一些共同之处，剩余的细节留给你自己去处理。
普查通常由接受评审的设计或代码的主持者所采用。

·  普查的目的是为了提高程序的技术质量，而不是评估程序。
·  所有参与者通过阅读设计或代码为普查做准备并寻找错误。
·  普查可为老资格程序员向新手提供传播经验和合作精神的机会，它也为年轻的程序员
提出新方法，并向一些过时的结论挑战提供机会。
·  普查通常需花费 30 到 60 分钟的时间。
·  普查侧重于发现错误，而不是纠正错误。
·  管理人员并不参加普查。
·  普查这个概念是灵活的，它也适应于特定的场合。

 

 

在排除错误方面，检查比普查显得更为有效。但是为什么有人爱用普查呢？
如果你拥有一个较大的评审组，普查不失为一种较好的评审方法，因为它给接受评审的程
序带来多种不同的见解。如果所有参加普查的人都相信解答是正确的，就不会有大的缺陷。
如果有来自其它组织中的评审员，普查也可能是可行的。在检查中，每个人的职责分工是
明确的，在人们有效地运用它们之前需要一个实践过程，让以前未曾参加过检查的人当评审员
是不利的。如果你想让他们出一份力，普查可能是最好的选择。
检查比普查更有所侧重也能获得更好的收获。如果你想为所在组织选择一个评审标准,在作出选择之前好好考虑一下
 

代码阅读

 

代码阅读是对检查和普查的另一种选择。在代码阅读时，你能读源代码并寻找错误。你也
同时对代码的质量如其设计、风格、可读性、可维护性和有效性提出你的见解。
对美国宇航局软件工程实验室的一项研究表明，代码阅读平均每小时可发现 3.3 个错误。
调试平均每小时可发现 1.8 个错误（Card 1987）。代码阅读在软件生存期中要比其它调试方式
多发现 20%到 60%的错误。
  同普查一样,代码阅读的定义并不严格。代码阅读通常是二人或多人各自阅读代码然后和代
码的开发者一起讨论。以下是阅读的方法：
    ·  在开会之前，代码开发者将源代码分发给代码阅读者。代码长度通常从 1000 到10000
行不等。典型的是 4000 行。
  ·  一个或多个人共同阅读代码。最少应有 2 个人，以便激励在评审者间的竞争。如果你
使用的人数多于 2 个，你应度量每个人的贡献，以便了解多余的几个人究竟有多大的
贡献。
·  评审者独立地阅读代码。其速度大约是每天 1000 行。
  ·  当评审者完成代码阅读后，代码开发者主持召开代码阅读讨论会。会议持续时间为 1
个或 2 个小时，其侧重点是代码阅读者所发现的问题。通常人们并不是一行一行通读
代码。本会议不是必需的。
  ·  代码开发者确定由评审者所发现的错误。
  代码阅读和检查、普查的区别在于代码阅读侧重于个人对代码的评审,而不是着重于会议上
的讨论。其结果是,评审者的时间大都花费在寻找代码的问题了。这样，花费在开会上的时间将
减少因为每人只需花费少部分时间在这上面。因为会议所花时间对一个中等组来说是可观的。
除非各组员能在二小时内碰头,开会耽搁的时间也少。代码阅读在当评审员不在一起时是相当有
价值的。

 

 

小  结

 

  ·  总的来说，评审在发现错误方面较测试要好。
  ·  评审侧重于错误发现而不是纠错。
  ·  评审往往比测试要能发现更多种不同的错误，意味着你应使用评审或调试方法以确保
软件的质量。

·  使用检查表、准备良好的分工、连续的处理以便最大限制地提高检错能力，检查往往
较普查能发现更多的错误。
  ·  普查和代码阅读是检查的候补方法。代码阅读可有效地利用每个人的时间。