<文献翻译一：原文>
CodeInspections[1]
A code inspection is a set of procedures and error-detection techniquesfor group code reading. Most discussions of code inspections focus on theprocedures, forms to be filled out, and so on. Here, after a short summary ofthe general procedure, we will focus on the actual error-detection techniques.
Inspection Team
An inspection team usually consists of four people. The first of thefour plays the role of moderator, which in this context is tantamount to thatof a quality-control engineer. The moderator is expected to be a competentprogrammer, but he or she is not the author of the program and need not beacquainted with the details of the program. Moderator duties include:
l Distributing materials for, andscheduling, the inspection session.
l Leading the session.
l Recording all errors found.
l Ensuring that the errors aresubsequently corrected.
The second team member is the programmer. The remaining team membersusually are the program’s designer (if different from the programmer) and atest specialist. The specialist should be well versed in software testing andfamiliar with the most common programming errors, which we discuss later inthis chapter.
Inspection Agenda
Several days in advance of the inspection session, the moderatordistributes the program’s listing and design specification to the otherparticipants. The participants are expected to familiarize themselves with thematerial prior to the session. During the session, two activities occur:
1. The programmer narrates, statement by statement, the logic of theprogram. During the discourse, other participants should raise questions, whichshould be pursued to determine whether errors exist. It is likely that theprogrammer, rather than the other team members, will find many of the errorsidentified during this narration. In other words, the simple act of readingaloud a program to an audience seems to be a remarkably effectiveerror-detection technique.
2. The program is analyzed withrespect to checklists of historically common programming errors (such achecklist is discussed in the next section).
The moderator is responsible for ensuring that the discussions proceedalong productive lines and that the participants focus their attention onfinding errors, not correcting them. (The programmer corrects errors after theinspection session.)
Upon the conclusion of the inspection session, the programmer is givena list of the errors uncovered. If more than a few errors were found, or if anyof the errors require a substantial correction, the moderator might makearrangements to reinspect the program after those errors have been corrected.This subsequent list of errors is also analyzed, categorized, and used to refinethe error checklist to improve the effectiveness of future inspections.
As stated, this inspection process usually concentrates on discoveringerrors, not correcting them. That said, some teams may find that when a minorproblem is discovered, two or three people, including the programmerresponsible for the code, may propose design changes to handle this specialcase. The discussion of this minor problem may, in turn, focus the group’sattention on that particular area of the design. During the discussion of thebest way to alter the design to handle this minor problem, someone may notice asecond problem. Now that the group has seen two problems related to the sameaspect of the design, comments likely will come thick and fast, withinterruptions every few sentences. In a few minutes, this whole area of thedesign could be thoroughly explored, and any problems made obvious.
The time and location of the inspection should be planned to preventall outside interruptions. The optimal amount of time for the inspectionsession appears to be from 90 to 120 minutes. The session is a mentally taxingexperience, thus longer sessions tend to be less productive. Most inspectionsproceed at a rate of approximately 150 program statements per hour. For thatreason, large programs should be examined over multiple inspections, eachdealing with one or several modules or subroutines.
Human Agenda
Note that for the inspection process to be effective, the testing groupmust adopt an appropriate attitude. If, for example, the programmer views theinspection as an attack on his or her character and adopts a defensive posture,the process will be ineffective. Rather, the programmer must a leave his or herego at the door and place the process in a positive and constructive light,keeping in mind that the objective of the inspection is to find errors in theprogram and, thus, improve the quality of the work. For this reason, mostpeople recommend that the results of an inspection be a confidential matter,shared only among the participants. In particular, if managers somehow make useof the inspection results (to assume or imply that the programmer is inefficientor incompetent, for example), the purpose of the process may be defeated.
Side Benefits of the InspectionProcess
The inspection process has several beneficial side effects, in additionto its main effect of finding errors. For one, the programmer usually receivesvaluable feedback concerning programming style, choice of algorithms, andprogramming techniques. The other participants gain in a similar way by beingexposed to another programmer’s errors and programming style. In general, thistype of software testing helps reinforce a team approach to this particularproject and to projects that involve these participants in general. Reducingthe potential for the evolution of an adversarial relationship, in favor of acooperative, team approach to projects, can lead to more efficient and reliableprogram development.
Finally, the inspection process isa way of identifying early the most error-prone sections of the program,helping to focus attention more directly on these sections during thecomputer-based testing processes (number 9 of the testing principles given inChapter 2).
<文献翻译一：译文>
代码检查
代码检查是一项以小组为单位来阅读代码，集合了一系列规章程序和错误检查规范的技术。大部分对于代码检查的讨论都是集中在程序和所要填写的表格之中以及其他流程当中， 在这里本文将对整个完整的规章程序进行简单的概述，之后将重点讨论实际之中所产生的错误检查技术。
代码检查小组
通常情况下代码检查的小组由4个人组成。其分工如下，在这四人之中的其中一人有着协调的作用。这个起着协调作用的人需要是一个程序员，但是他或者她并不需要是这个程序的编写者，也不需要特别了解这个程序的细节。这个协调人员主要负责以下几点：
l 对代码检查任务进行安排，将代码检查的所需资料分配给组内的其他人员。
l 在代码检查的任务中起到了领头的作用。
l 在检查过程中实时记录所有发现的错误。
l 确保被发现的所有错误都能在最后被解决。
在团队的另外三个人之中有一位成员是程序员。剩下的两位团队成员通常是程序的设计者（如果该程序的设计者与程序的编写者不同的话）和测试专家。测试专家应当精通软件测试，熟悉最常见的编程错误，本文将在本章后面部分的讨论中提到这些问题。
检查议程
整个团队在开始代码检查之前，那个起着协调作用的人需要把相关代码清单和程序设计规范分发给团队的其他人员。所有参与代码检查的团队成员都需要在任务开始之前了解并熟悉材料。在开始代码检查任务之后，主要有两项任务需要完成：
1. 由程序的编写人员逐字逐句的给其他人讲解程序的逻辑结构。在讲解过程之中，团队中的其他参与者应该提出问题，来判断该程序之中是否存在错误。在讲述的过程中也有可能是程序的编写人员，而不是团队中的其他成员发现了程序之中的错误。换句话说，对着听众大声朗读程序之中的代码，这个方法虽然看似简单但其实也是一种非常有效的错误检查方法。
2. 参考其他容易出现的代码编写错误列表来分析此程序。(诸如此类的代码错误列表会在下一章节中讲述)。
协调人员的主要责任是确保当前的讨论能够按照计划，顺利并且高效的进行，团队的参与者需要将注意力集中在发现错误，而不是如何去改正这些错误。（纠正发现的错误会在完成了检查议程之后由程序员来完成。）
在检查议程结束之后，程序员会列出了一个已经发现错误代码的列表。如果发现的代码错误实在太多了，或者如果有严重影响到整个程序框架的重大错误需要大幅修正，协调人员可能需要在修复了这些错误之后重新安排检查议程对修复后的程序再次进行检查。这之前所写的错误列表也需要进行分析，归类，以便日后再次进行代码检查的时候可以再次使用这份清单，来提高未来检查代码时的效率。
综上所述，这个检查过程通常将重点集中于发现错误，而不是去纠正错误。也就是说，如果团队中有可能发生当有两到三个人发现了一个小问题，其中包括负责代码部分的程序员本人，会提出建议去处理来解决这种特殊情况。那么针对于这个小问题的讨论可能会反过来将小组的注意力集中在这个设计的特殊部分上。在讨论改变设计来处理这个小问题的最佳方法时，有人可能会注意到其他的类似问题。因为现在该小组已经看到了设计中同一个部分的两个相关的问题，那么每隔几段代码可能都会需要进行密集的注释，在几分钟之内，整个程序的代码设计部分就能被彻底检查完，出现的任何问题都能够清楚明了的展示在检查人员的面前。
关于在代码检查计划的时间以及地点的选择上，为了防止所有的外界干扰，检查人员进行代码检查的最佳时间为90到120分钟。由于代码检查是一项需要繁重脑力劳动任务的经历，因此代码检查的时间越长，工作的效率越低。大多数的代码检查都按每小时约150行程序代码的速度进行。因此，对大型软件来说，需要安排多个代码检查小组同时进行代码检查以保持高效率的运作，每个代码检查流程都会涉及一个或多个模块或子程序。
有关于人的议程
值得注意的是，要使得代码检查的过程快速有效，测试组必须保持适当的正确态度。举一个例子，如果程序员认为，进行代码检查是对他或她本人的人格的一种攻击，并采取了防范姿态拒绝为组内的其他人员讲解代码的原理，那么这个检查的过程将是收效甚低的。正确的做法是，程序员必须抛开他或她的自负和高傲的态度，以积极和建设性的眼光来看待代码检查这件事，需要记住的是，代码检查的目的是为了发现程序中所包含的错误，从而提高工作质量。出于这个原因，大多数人建议应当对代码检查的结果进行保密，只有参与者之间才可以共享检查的结果。尤其是，如果管理者想利用检查的结果（例如有可能会去暗示编写这段代码的程序员是否称职，技术是否完善），那么就和代码检查的真实目的背道而驰了。
检查代码的衍生功效
代码检查除了其可以发现大部分在写代码时产生的错误这个主要作用之外，还有好几个方面的衍生作用。首先，程序员通常会收获关于编程风格、算法选择和编程技巧等几个方面的有价值的反馈。其他参与者也可以通过接触另一位程序员产生的错误和编程风格来获得更多的经验。一般来说，这种类型的软件测试方法有助于加强团队对这个特定项目和涉及这些参与者的项目的理解。减少团队中人际关系的负面增长，有利于打造高度合作高效率以及高度互信的开发模式。
最后的最后，代码检查过程是能够在程序早期最容易检查出出错部分的一种方法，有助于在使用计算机软件的测试过程中能将更多的注意力集中在这些部分（与第2章第9条测试原则有异曲同工之妙）。
扫一扫
957
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
