4软件技术评审

目录目录第一章第一章质量的挑战质量的挑战.11.11.1 查看他人的工作查看他人的工作.11.21.2 质量并不免费质量并不免费.21.31.3 合理评价同级评审合理评价同级评审.41.41.4 同级评审、测试和质量工具同级评审、测试和质量工具.51.51.5 能够评审什么能够评审什么.71.61.6 对质量的个人承诺对质量的个人承诺.8第第 2 章章 来自朋友的帮助来自朋友的帮助.92.12.1 查找别人的错误查找别人的错误.92.22.2 评审和小组文化评审和小组文化.102.2.1 文化的影响.102.2.2 评审与管理者.112.2.3 为什么人们不愿意实施评审.132.2.4 克服对评审的抵触情绪.142.32.3 同级评审的评审级别同级评审的评审级别.162.42.4 为评审制定方案为评审制定方案.172.52.5 评审的指导原那么评审的指导原那么.19第第 3 章章 同级评审方法的正式化频谱同级评审方法的正式化频谱.203.13.1 正式化频谱正式化频谱.203.1.1 审查.213.1.2 小组评审.223.1.3 走查.233.1.4 结对编程.243.1.5 同级桌查.253.1.6 轮查.253.1.7 临时评审.263.23.2 选择适宜的评审方法选择适宜的评审方法.26第第 4 章章 审查过程审查过程.284.14.1 审查角色审查角色.284.1.1 作者角色.284.1.2 读或不读.294.24.2 审查小组的规模审查小组的规模.304.34.3 审查过程的各个阶段审查过程的各个阶段.304.3.1 制定方案.324.3.2 总体会议.334.3.3 准备.334.3.4 会议.334.3.5 返工.344.3.6 跟踪.354.3.7 因果分析.354.44.4 不同的审查方案不同的审查方案.354.4.1 GILB/GRAHAM方法.354.4.2 HIGH-LMPACT审查.364.4.3 分阶段审查.36第第 5 章章 制定审查方案制定审查方案.385.15.1 何时进行审查何时进行审查.385.25.2 审查的评审组长审查的评审组长.405.35.3 选择审查材料选择审查材料.415.45.4 审查准入条件审查准入条件.425.55.5 聚集各方观点聚集各方观点.435.5.1 审查者的视角.435.5.2 管理者和观察者.455.65.6 审查包审查包.465.75.7 审查速率审查速率.475.85.8 制定审查活动进程表制定审查活动进程表.48第第 6 章章 检查工作产品检查工作产品.506.16.1 总体阶段总体阶段.506.26.2 准备阶段准备阶段.516.36.3 准备的方法准备的方法.536.3.1 缺陷检查表.546.3.2 规那么集.556.3.3 其他分析技术.55第第 7 章章 齐心协力进行审查齐心协力进行审查.597.17.1 评审组长的角色评审组长的角色.597.27.2 启动审查会议启动审查会议.627.37.3 举行会议举行会议.637.3.1 读工作产品.637.3.2 发现缺陷和问题.657.3.3 记录缺陷和问题.667.3.4 观察问题.687.47.4 产品决议产品决议.707.57.5 结束会议结束会议.717.67.6 改良审查过程改良审查过程.72第第 8 章章 结束审查结束审查.738.18.1 返工阶段返工阶段.738.28.2 跟踪阶段跟踪阶段.748.38.3 因果分析阶段因果分析阶段.758.48.4 审查准出条件审查准出条件.76第第 9 章章 分析审查数据分析审查数据.789.19.1 为何要收集数据为何要收集数据.789.29.2 关于测量的说明关于测量的说明.799.39.3 根本数据项和度量根本数据项和度量.809.49.4 审查数据库审查数据库.819.59.5 数据分析数据分析.839.69.6 测量审查的效果测量审查的效果.859.6.1 有效性.859.6.2 效率.869.6.3 投资回报.86第第 10 章章 建立同级评审程序建立同级评审程序.8910.110.1 同级评审过程拥有者同级评审过程拥有者.8910.210.2 组织准备组织准备.9010.310.3 过程资产过程资产.9310.410.4 同级评审协调者同级评审协调者.9410.510.5 同级评审培训同级评审培训.9510.610.6 实验评审过程实验评审过程.97第第 11 章章 让同级评审发挥作用让同级评审发挥作用.9911.111.1 关键成功因素关键成功因素.9911.211.2 需防止的评审陷阱需防止的评审陷阱.10111.311.3 评审问题的解决评审问题的解决.102第第 12 章章 特殊评审的挑战特殊评审的挑战.10712.112.1 大件工作产品大件工作产品.10712.212.2 空间和时间上的别离空间和时间上的别离.10812.2.1 分布式评审会议.10912.2.2 异步评审.10912.312.3 生成的和非过程的代码生成的和非过程的代码.11012.412.4 有太多的参与者有太多的参与者.11112.512.5 缺乏合格的评审人员缺乏合格的评审人员.111尾声尾声.113附录附录 A .114附录附录 B.121同级评审的术语表同级评审的术语表.122第一章第一章 质量的挑战质量的挑战“嗨，Maria，你有时间吗？我找不到程序中的一个小缺陷，你能帮我看一看这段代码吗？“当然可以，Phil，哪里有问题？“这些图像没有正确对齐，它们应该全部左对齐，但每一个都是缩进排列。我确信问题出在DisplayImage 函数，但我已研究了 15 分钟，没能发现任何错误。“嗯，让我看看。它好似细细低语“不，那局部是对的，但请看这个循环的起始处。Maria 指着屏幕说， “我认为这个括号放错了位置。如果你将索引变量移至外面，图像将不会缩进排列。Phil 用手拍着额头，说道“你是对的!真谢谢你，Maria，我简直不能相信我没有发现那个错误。“太客气了，Phil，我很乐于帮助。许多程序员都曾经请求同事帮助寻找代码中不易发现的问题。因为身在其中而常常不能发现自己的错误。当研究代码时，你的大脑正在重复原有的思维活动，以同样的原因重复原有的错误。你需要从一个新的角度出发：一双从未看过这些代码的眼睛和一个以不同思维方式思考的大脑。1.1 1.1 查看他人的工作在同级评审中，由生产产品的作者以外的其他人来检查工作产品，发现缺陷，并寻找改良的契机。所谓缺陷defect，或错误 ，是指软件工作产品中的一种情况，它将导致软件产生不令人满意或非预期的后果。当 Phil 陷入困境时，他请 Maria 来做一次简单的代码评审。Maria 只用几分钟的时间研究了问题代码，然后就将他从困境中解救出来。即使你的组织中采用了正式的同级评审过程，还是要依靠同事的热心帮助来进行这些临时的快速的评审。为了发现缺陷，人们采用了包括同级评审在内的多种工程评审，表 1-1 给出了其中的一些方式。虽然所有的评审对工程的成功都有帮助，并且也可能涉及作者的“同级同事，但本书的重点在于同级评审，其首要目的就在于提高产品的质量。表格 一-1 工程评审的类型评审类型评审类型目目 的的教育评审管理、预备、或准入评审同级评审工程后的评审状态评审让其他工程相关人员来催促与工程相关的技术论题向上层管理者提供信息，以帮助他们做出如下决策：发布产品、继续或取消开发工程、批准或拒绝提案、改变工程范围、调整资源、改变承诺寻找工作产品中的缺陷和改良契机对最近完成的工程或阶段进行评审，让未来的工程吸取经验向工程经理和其他工程成员提供最新的工程状态信息，包括里程碑的进度、所遇的问题、识别的或受控的风险术语“同级评审有时被误认为是对同事的绩效评估。事实并非如此，任何同级评审都是针对工作产品，而不是创立工作产品的个人。同级评审已成为科学和工程工作的根本构件。一个科学家的同事能够判断工作是否满足专业标准，能够在实验或设备设计、数据收集或结果分析中发现错误。科学的结论只有当其通过了同级评审之后才会被考虑其有效性。这对于软件开发也是一个不坏的哲理。多种广泛使用的过程改良框架都把同级评审作为组织必须采用的关键实践，以提高软件工程能力，参见附件 A。当我使用“评审或“同级评审术语时，是指软件同级评审的总体活动，而不精确地考虑它如何具体进行。术语“评审、 “审查和“走查有时可交换使用，但它们代表了同级评审的不同方法。第 3 章表达了从非正式评审如 Phil 和 Maria 的经历到高度系统化和标准化的审查过程的一系列同级评审方法。第 3 章也建议了专门的评审技术，以满足特殊工程的要求。评审的目标不仅是捕捉错误，收集改良的建议，而且帮助作者在未来创立更好的工作产品。我曾经以作者或评审者的角色参与了屡次评审，从中学到了不少。同级评审的好处是如此突出，以致我不愿在不设同级评审的组织中工作。1.2 1.2 质量并不免费管理者、开发人员和客户有时反对同级评审，因为他们认为评审的花费太大，并将减慢工程的进度。事实上，评审并不会减慢进度，缺陷却会。任何一个经历过疯狂的测试一调试过程的人都会认识到后期发现缺陷的昂贵代价，这将使得最终产品延期交付。只有当你的工作产品在评审时未能发现缺陷，评审才是浪费时间。可能你听到过质量是免费的论点Crosby l979 。这有些过于简单化了。 “质量是免费的意味着你在产品质量上的投资超过了减少后期缺陷和客户报告的问题的回报。另一种观点是将缺陷对工程和产品的影响考虑为质量本钱，它包括以下几类活动所花的时间和资金：外部产品失效，包括处理客户报告的缺陷，开发代码补丁或未列入方案的发布，以及实现遗漏的功能。内部产品失效，例如纠正在测试或产品发布前同级评审发现的缺陷，缺陷管理，缺陷构件的返工，和重新测试修改后的构件。质量评估，如执行评审或测试来发现缺陷，收集和分析质量度量。缺陷预防，包括培训开发人员，分析缺陷产生的原因，开发和改良工程和质量过程。返工重做你认为已经完成的事情所花的时间是一个工程质量本钱的最主要局部。如果许多小的纠正活动花费了数小时的工作，返工就会对软件开发的生产率造成很大损害。根据一些企业返工度量的报道，它可占整个开发工作量的 4060CJones l986；Cooper and Mullen l993；Haley l996；Wheeler，Brykczynski，and Meeson Jr1996b 。虽然评审消耗了资源，不是免费的，但在评审上所花的时间能够减少大量工程后期的返工。那些被防止的返工时间可用于开发工作，这对你的顾客和业务都是十分值得的。在同级评审上的投入把组织的一些质量本钱从昂贵的、后期的返工转变为早期的缺陷发现。更重要的是，工作产品的作者学到了如何将工作做得更棒，从而防止了缺陷。不管你有没有发现它们，缺陷总是存在的，问题只是当最终发现它们时，需要多少纠正本钱。例如，Raytheon 电子系统在两年中将返工率从工程总开支的 41降低到 20，这在很大程度上归功于执行了审查程序Haley l996 。Raytheon 同时还减少了 80代码集成过程中问题纠正的工作量，并削减了一半的重新测试工作量。评审同样也改良了开发过程，通过缺陷预防提高了组织的效率，这是一种巨大的战略利益。预防缺陷比你完成实现或交付产品后再去除它们更廉价。在开发后期或在产品发布后发现并纠正缺陷的费用很高，因而在产品开发早期检测缺陷将有很大的潜在回报。航天飞机搭乘软件工程的测量结果是，如果在审查时纠正设计或代码的相对本钱为 1 美元，那么在系统测试时为 l3 美元，在交付后那么为 92 美元Paulk et al1995 。另一些研究说明，纠正客户报告的与需求相关的缺陷的费用是在需求开发阶段发现和纠正同样缺陷的 68倍ll0 倍Boehm l981；Grady l999 。我的某个咨询客户是一个电信公司，它们利用审查发现和纠正一个缺陷的平均费用为 200 美元，而改正一个客户发现的缺陷平均花费 4200 美元。这个放大倍数对于不重要的小系统没有这么严重，但绝对不会是零Boehm and Basili 2001 。你可以用评审来评价产品质量的其他方面，如可靠性、健壮性、可维护性和可测试性。如果创立和维持评审程序、培训团队和执行评审的费用投入低于由于减少返工而节约的费用和由于提高客户满意度所产生的回报，那么你就已经迈出了一大步。每个工程组必须在初期产品质量和其他业务目标的投入之间取得平衡，其他业务目标包括上市时间、产品特性和长期的维护费用等。大家都认为，对于一个以进度驱动的工程而言，评审是它所不能负担的奢侈行为。是的，评审需要花费时间，但是，是否它们花费得太多，那么是商务问题，当评审应用得好时，它实际上可以通过绕过一些测试阶段来缩短产品开发进度Weller l993 。从长远利益看，关于质量的实践活动可以更快地推出“足够好的产品。有时管理人员或市场人员却决定不执行质量活动，他们在试图满足紧迫的交付进度与付出更多的资源进行问题纠正之间进行了商务折衷。这样的决策必须基于对质量本钱及其蕴含的商务可能性所进行的风险评估。如果管理者认识到长期的质量需求，他们就会在工程进度中安排评审的时间。在当今的互联网世界中，上市时间常常被看作是最重要的因素。而对一个低质量的电子商务工程而言，由于存在产品缺陷，其代价将包括商业时机的丧失。 “足够好的质量是指产品必须对客户而言是足够好的，愿意屡次使用。我读过对一个新的飞行模拟游戏的评论“评审的另一种不同的定义说：“但是，软件没有完成，并被可怕的缺陷、文档的差异和支离破碎的功能所折磨Dy 2001 。对于开展中的公司，推迟发布一个更高质量的产品可能会更好，这样能防止这种负面的评论。另一个例子是，我曾经在网上从供给商那里为我的支票账户订购新的支票，当我一周后询问时，供给商却没有我的订单记录。Web 站点确认已接受了我的订单，所以我只能推断软件的缺陷导致了用户我的不方便。以后我再也不光临那个网站了。评审不会发现产品中的所有缺陷，但是它们是你的缺陷检测工作的一局部。在同级评审上花费时间将能真正地加快产品的上市时间，不会延误。你需要评估每个产品中未发现的遗留缺陷的可能性，估计它们可能造成的影响，这样你就可以决定在质量上投入多少。下面列出了从业务角度进行自我提问的一些问题例如：中断电信系统的两小时工作的代价将是什么?因为一个评审中应能发现的缺陷而造成宇宙飞船迷失方向的损失有多大?讨论组的一次不良产品评审或负面意见将如何影响你的新电脑游戏的销售或你将来的职位?和按时启动带有严重平安缺陷的 Web 站点相比，修改后晚一周启动对你造成的损失如何?嵌入在汽车平安设备中的缺陷代码，如气囊系统，对可靠性会造成什么不利?1.3 1.3 合理评价同级评审虽然没有人能精确预测一个组织从新的实践中获得的投资回报率ROI ，许多公司已报道了从审查中获得的显著回报。非正式评审因为一般不收集数据，因而拿不出许多数据。直到你积累了足够的数据来展示自己的 ROI，你才可能得到信任。管理者和技术人员应该尊重审查，愿意在几十年经验的根底上去尝试。下面列出了审查实践者从中获得的一些回报：HP 公司测量所得的审查投资回报率为 10：1，每年节省 2140 万美元。在设计过程中进行审查缩短了 l8 个月的上市时间Grody and Van Slack l994 。在 AT&T 贝尔实验室，审查使得发现错误的费用降低到 l0，同时使质量提高了 l0 倍，效率提高了 l4Humphrey l989 。贝尔北方研究中心审查了 250 万行实时系统代码，防止了平均每个缺陷 33 小时的维护费用。通过审查发现缺陷的效率是测试的 2-4 倍Russell l991 。IBM 公司报道，每小时的审查可节约 20 小时的测试，如果在发布的产品中遗留了审查发现的缺陷，那么所需的返工时间为 82 小时Holland l999 。在广泛采用审查的五年中，Primark 投资管理公司总共节约了 3 万小时的人工。Primark同时看到了平均每年每个客户报告的产品错误降低到原来的五分之一Holland l999 。在皇家化工公司中，维护经审查的 400 个程序的费用是维护类似的未经审查的 400 个程序的费用的十分之一Gilb and Graham l993 。Litton 数字系统在审查中投入了总工程工作量的 3，从而使得系统集成和系统测试发现缺陷的数量减少了 30。设计和代码审查减少了一半的产品集成工作量Madachy l995 。同级评审的效率应以节约了工程组多少工作时间来计算，而不是根据它们发现多少缺陷。第9 章描述了在具体组织中估算评审 ROI 的过程。记住，如果拙劣的评审未能发现任何缺陷，或者发现的缺陷未能纠正，或者在培训和开发了同级评审过程后工程组未能真正实施评审，那么 ROI的值将是零。同级评审带来了不少难以计数的额外回报。其中之一是从他人对自己工作的反响中获得的知识。评审在工程成员间传播产品、工程和技术知识，补充了正规的交流和培训机制。它们帮助小组建立共同的期望，发现假设，建立对技术工作产品一致的认识。评审帮助实践者开发简单和易理解的产品，减少维护和改良的本钱。正如 Donald Knuth 指出，编写程序要让人和编译器都能读懂Knuth l992 。当开发人员知道其他人将检查这些程序时，他们会更加仔细地编写结构良好的、文档化的、高质量的程序。评审有助于建立合作精神，小组成员愿意分享他们的知识，彼此学习，为每个系统构件而努力。开发人员不仅理解自己的构件，而且学习应用构件，这为每个人的工作提供了更清晰的环境。通过同级评审相互培训，彼此交换知识，从而降低了因人员跳槽而丧失关键信息的风险。同级评审带来的这些回报几乎总是超过它们的花费。1.4 1.4 同级评审、测试和质量工具质量控制活动决定了一个产品是否符合它的需求、标准或参考标准。两者不一致就会导致缺陷。在开发过程中进行质量控制验证比在完成产品后寻找错误确认更为有效。同级评审是一种验证手段，你可以用它在产品完成前改良产品。动态测试只有在软件产品或构件完成后才能发现质量低劣之处。而且测试无法说明产品符合标准。高效的软件实践者拥有一组丰富的质量技术工具。除了传统测试和同级评审，还可有许多商业化的软件质量工具产品。它们包括静态分析器，它能够检查源代码，发现可能的错误；运行问题的检查工具，如检查内存漏洞和指针问题。当存在如此多其他的质量工具时，开发人员有时会对人工代码评审的价值产生疑心。这些工具和实践是相互补充的。代码分析器能够发现细微的语法错误和可能的问题域，如人们用肉眼可能没有发现的未初始化的变量，但它并不检测逻辑错误。同样地，一个字处理软件的拼写检查器将捕捉到需求规格说明中的单词拼写错误，但它不能去除错误的、模糊的或遗漏的需求，或者单词的不正确使用。测试不会告诉你代码的清晰度或可维护性，但是开发人员却能在评审中判定这些质量。一个评审人员能够发现模糊的出错信息、不充分的注解、难以理解的变量值，以及可以合并的重复代码模式。尽管代码分析器能标识出人们可能没有注意到的那些执行所无法到达的代码，但是测试不会发现多余的代码。你可以用测试覆盖分析器来识别出未测试的代码，如很难触发的异常处理，然后在人工评审中特别地注意这些代码。在一次研讨会上，一名学生曾经断言同级评审是多余的，坚持认为测试可以更快地发现所有的错误。这是一个很普遍的错误想法。IBM 的 Santa Teresa 实验室发现，采用代码审查发现一个主要缺陷的平均花费为 3.5 小时，而测试却要花费 15-25 小时Kaplan l995 。在单一的测试阶段，你不可能去除被测工作产品中超过 35的缺陷。相反地，设计和代码审查一般却能发现5070的缺陷C.Jones l996 。非常有经验的审查者能去除 90的缺陷。除非你使用了代码覆盖分析器来度量你的单元测试，否那么你很可能没有测试到 60的代码M .Johnson l994 。没有覆盖分析器，你不知道哪些代码没被测试案例执行。但是在同级评审中你非常清楚地知道你所检查的代码。测试可以发现系统没有按预期地运行，然后你不得不通过调试来发现潜在的缺陷。但是在评审中，你可以直接寻找问题，而不是寻找其间接病症。评审同时可以暴露测试工具可能无法检测的缺陷。例如，如果对话框中的一个按钮不能正常工作，你就不得不先修改它，然后才能再测试单击按钮后出现的画面。但是尽管按钮有缺陷，却仍可评审第二个画面。同级评审是在需求和设计规格说明、工程方案、用户手册和类似文档的最好的查错工具。除了人工评审，你还能如何“测试你的测试方案、设计和案例?在多步骤的过程如软件开发中，任何一个过程步骤的输出质量受其输入质量的限制。图1-l 展示了软件开发过程中典型的活动顺序，在每个主要检查点上都需要进行评审。该图和大家常常批评的瀑布模型很相似，但它并不要求你一定要在开始设计之前完成所有的需求，并在编码开始前完成设计。许多工程常常通过连续的开发方式构建产品，每次发布一个功能更强的版本。无论你采用哪一种开发生命周期，同级评审都能把好这个重要的质量关，在你进行下一个活动之前，每个主要的可交付产品必须通过同级评审，这些产品是下一个活动的根底。不要期望用测试代替同级评审，相反地，应将评审放到质量工具箱中。对于产品质量的提高，评审常常能比测试更廉价，它们能减少测试的费用和时间。例如，根据一个操作系统的开发组织报道，由测试发现一个设计错误平均花费 8.5 小时，而审查只需 l.4 小时Ackcrman，Buchwald，and Lewski l989 。将评审与静态和动态代码分析器、动态测试、测试覆盖工具和交互调试器进行有机的结合，能提供强大的错误检测能力。图表 一-1 软件工程中的主要评审检查点1.5 1.5 能够评审什么虽然许多人将代码和同级评审联系在一起，事实上，任何软件工程或工程管理的工作产品都能从同级评审中获益。IEEE 的“软件评审标准Std l028-1997列出了 37 种可以评审的与软件相关的工作产品IEEE l999b 。以下是可以评审的一些可交付产品：市场文档、需求规格说明、用例和分析模型。业务过程模型和业务规那么。工程章程和各种工程方案工程管理方案、任务列表、进度、配置管理方案、质量保证方案、风险管理方案等等 。体系结构描述。用户界面设计和原型Nielsen and Mack l994；Constantine and Lockwood l999 。软件和数据库设计描述和模型。源代码，包括脚本、宏和存储过程等。程序文档和系统维护文档。测试方案、设计、案例和过程。用户指南、参考手册、帮助屏幕、指导书、培训资料、领域和客户支持手册。建立、发布、安装过程。软件开发规程、标准、和过程描述。本书中的软件评审方法可用于非软件工程的工作产品，但也必须用于具有正确性、连续性和一致性的非技术文档。因为在工程开发过程中缺陷纠正费用不断放大，评审早期产品可以起到最好的作用。某跨国图像公司的一个部门统计说明，在五年中审查需求规格说明的 ROI 是 10：1。在洛克希德马丁西部开发实验室，对需求文档的审查每小时发现的缺陷数比对设计或代码审查发现得更多Bourgeois l996因为需求是工程中的其他工作的根底，对需求文档的正式审查可能是软件质量实践中最重要的活动。1.6 1.6 对质量的个人承诺在我高中化学教室的墙上有一条标语问道：“如果你没有时间将它做对，你还会有时间把它做完吗？在软件业，人们应该将这句话记在心里。如果你没有时间采用同级评审来提高产品质量，你将需要更多的时间去纠正测试人员或客户发现的缺陷。请利用你积累的评审经验来提高开发过程，以使你的团队成员在他们的工作中少犯错误，从而节省更多的时间。我们将在第 2 章讲到，同级评审对团队所起的作用取决于团队的文化和团队成员的态度。如果你非常重视个人工作的质量，在犯错误时，你会乐意接受同事的意见以发现错误，并愿意评审同事的工作产品。你将放弃自满，这样才能从同事的经验和观点中获益。当你已从同级评审中真正获益时，一旦你所创立的重要产品没有被其他人仔细检查过，你将不会感到欣慰和放心。第第 2 章章 来自朋友的帮助来自朋友的帮助请别人指出你工作中的错误是一种学习的行为，而不是一种本能的行为。我们常常会对自己所做的工作感到骄傲，而不愿成认工作中所犯的错误。我们甚至根本不知道已经犯了多少错误，更不用说要纠正这些错误。我们也不愿请别人帮助找错。但如果你想成功地完成同级评审，你就必须克服这些天生的对外界批评的抵触。同级评审是一种技术实践过程，也是一种社会交互的过程。要在一个组织中实施某种评审方案，需要对这个组织的文化背景以及其成员的价值观有充分的了解。只有工程经理认识到花在工程评审上的时间是值得的，他才会给整个工程组足够的时间去实施工程评审。你需要搞清楚有些人为什么不愿将他们的程序拿给同事评审，然后来解决这种抵触情绪。你还必须对小组成员以及工程经理进行同级评审的培训，内容包括同级评审的过程、正确的评审行为以及朋友的帮助将给个人乃至整个组织带来的好处等。2.1 2.1 查找别人的错误繁忙的程序员有时不太愿意花时间帮同事检查错误。你可能会狡猾地躲避要求你帮助查找代码错误的同事。是他缺乏信心？还是他想要你帮他考虑问题？一些反对工程评审的人说：“任何需要别人帮助检查代码错误的程序员都不应该得到软件开发者所应得的报酬。在良好的软件工程文化的环境中，小组成员会积极参与评审从而提高产品的质量和工作效率。他们知道即使不帮同事检查工作产品，在其他小组检查他们递交过去的产品时，同样要用掉那么多时间。我所知道的最好的软件工程师都会积极地为工程寻找评审人员。事实上，开发者的成功有一局部是属于评审者的。Gerald Weinberg 于 l971 年在?计算机编程的心理学?The Psychology of Computer Programming中首次提出了“无自我程序设计概念，并在 1998 年再次提到Weinberg 1998 。无自我程序设计指出了人们过多地将个人价值与设计工作联系在一起的事实。作为一个软件开发者，你可以将别人在工程中发现的错误解释为你自身缺点的一个表达，而这甚至适用于任何一个人。由于自负心理在作怪，你根本就不想知道你究竟犯了多少错。你的自负还使你将自己过分地保护起来，否认你犯错的可能性，并企图将可能存在的错误解释为所谓的特点。这种顽固的自我保护意识为有效地进行同级评审设下了障碍，导致错误地将个人对团队工程的奉献看作己有，也直接影响产品的质量。无自我程序设计让作者暂时退后一步，而让其他人指出作者产品中需要改良的地方。无自我程序设计的实践者也知道要让自己的产品更容易让人理解。相比之下，一些程序员以能写出晦涩难懂，只有他们自己能理解的所谓的聪明代码为乐，以为这能使他们看起来比那些努力想要读懂他们程序的人技高一筹。一位经理人高度评价这种无自我程序设计方法，认为通过这种方法能激发团队成员的合作意识和集体荣誉感，促进知识交流。要注意的是，这里提到的是“无自我程序设计，而不是“无自我程序员。人们有权保护他们的自我。程序员也需要足够强的自我意识才能对自己的工作有信心，并可保护他们的工作，但决不能过分自我以致拒绝别人提出的更好的解决方案。职业软件开发者以他们所创造的软件而骄傲，然而同时他们也意识到人是会犯错的，这时别人的观点会对自己大有裨益。无自我评审员会对同事的遭遇很敏感，且很容易产生同情心，因为他们知道有一天大家的角色会调换过来。2.2 2.2 评审和小组文化尽管个人总是能从同级评审中获益，但大局部评审只有在质量至上的价值观的文化背景下才能取得成功。 “质量有多层含义，包括没有错误、满足客户需求、按时交付以及令人满意的产品功能和特性。这种软件工程文化背景中的成员将评审当作一种有利于个人和团队成功的有建设性意义的活动。他们知道评审并不是为了找出蹩脚的程序员，或是为存在的质量问题找个替罪羊。评审会使作者对待其工作产品有两种不良态度。正如一些程序员完全依靠测试员来检测他们的程序中的错误，一些人会因而变得懒散起来。作者是最终负责产品的人，评审只是为了帮助作者设计出高质量的可交付产品。有时当我在阅读我写的某篇文章或某个章节的草稿时，我似乎听到一个声音在对我讲这个局部不够准确，或那个词用得不好。这时，我会习惯性地告诉自己：“我要把它拿给评审员看看，听听他们的意见。这是完全错误的：他们总是不喜欢那些笨拙的局部。因而现在，每当我听到那个声音，我总是在将它拿给别人看之前先仔细斟酌一番。另一个需要防止的极端是一些程序员在将产品交给别人看之前总想把它尽善尽美。这是一种自我保护策略：因为如果有人看到那些错误，你会感到为难。我曾经遇到过一位程序员，在她没有完成作品并且尽她的最大努力做到最好完全实现的、测试的、标准化的和文档化的之前，她不允许任何人看她的代码。她将评审看成是得到别人的认同，而不是提高产品质量的一种手段。这种犹豫不决的心理会导致不良的结果。如果你的工作只有在你认为已经完成的情况下才拿给别人评审，那你在心理上是拒绝别人的建议的。你会想：既然程序已经运行起来，它还会有多糟糕呢？由于你相信你已经完成任务并急迫地想要接受另一个任务，你会倾向于将可能存在的错误合理化。依靠你自己的桌面检查和单元测试，却忽略了高效率的同级评审，而它能查出更多的错误。与此同时，想要让同事看到自己最好一面的渴望也会带来正面效应。由于我们知道评审者会仔细检查我们的工作，因而评审会激发我们去实践更先进的技术，这样将间接地提高产品质量。我的一位参谋同事认识一位质量工程师，他将评审中发现的错误总结出来，拿给工程组中的所有成员看，而不指明具体的工作产品或作者。很快，工程组就发现评审中查找出的错误在减少。基于对小组的了解，我的同事得到如下结论：当作者学会如何在工程中使用评审以及了解所要查找的缺陷类型后，他们能开发出更好的产品。评审不是一种惩罚，而是鼓励大家圆满地完成工作。2.2.1 文化的影响文化的影响在健康的软件工程的文化气氛中，团队成员的共同理念、个人行为和技术实践方法构建了一个良好的环境。在此环境中，通过有效地实施合理化过程，工程组的所有成员共同负责开发高质量的产品Wiegers l996a 。这样的文化要求各级负责人都要共同负责营造以质量为驱动的环境。当每个成员都认识到成功要依靠大家之间的互相帮助，从而尽可能最好地完成任务时，大家就宁愿让同事而不是客户来发现软件中的缺陷。被同伴发现了错误被看成是“合算的，而不是个人失败。同级评审对健康的软件文化的影响最大，一次成功的评审会大大有利于这种文化气氛的形成。制定和维持有效的评审程序的先决条件包括：为你的每一个工程制定商业目标，以使评审员建立共享的工程愿景。确定你的客户对产品质量的期望，从而设置需到达的质量目标。充分了解同级评审和其他质量实践，以帮助小组到达预期的质量目标。对开发组织中的工程相关人员包括客户群体进行培训，让他们了解什么是同级评审，为什么它们会增值，谁应参与以及如何实施。安排必要的时间来制定和管理一个组织内的评审过程，培训参与者，实施评审，收集并评估评审数据。工作产品的作者和评审员之间的动态关系是非常重要的。作者必须信任和尊重评审员，并接受评审员的意见。同样，评审员也必须尊重作者的技能和辛勤劳动。评审员在提出问题时要慎重措词，并且把重点放在产品中所发现的问题。如果你说：“我没有找到变量初始化的地方，这暗示着你想要得到一个有建设性的答复，但如果你说：“你没有初始化变量，就可能使作者立刻警觉起来。言语中，将带有指责口吻的“你改为语气平和的“我能使评审员更有效地传达重要的反响。评审员和作者还要在评审工作之外继续保持协作的关系，他们需要保持职业精神和相互尊重，这样才能防止关系紧张。如果一位作者走出评审会议室时感到局促不安，觉得受到攻击，或自己的专业技能受到侮辱，那么他再也不会主动将自己的工作成果拿给评审小组评审。你肯定也不希望评审导致作者想要伺机报复那些使他难堪的人。评审过程中的“外分子是错误，而不是作者或评审者，但是假设要大家都认识这个事实，需要屡次积极的实践。评审负责人在评审之初就应该努力营造一种气氛，在这种气氛中每一位成员都尽力提出建设性的意见，并积极向同事学习，争取下一次做得更好。为了加速这种气氛的形成，工程经理应该鼓励和奖励评审的最初参与者，无论评审结果怎样。2.2.2 评审与管理者评审与管理者管理者对待评审的态度和实际行动直接影响着一个组织中评审执行的好坏。一方面他们想要开发出质量过硬的产品，另一方面他们又想尽快发布产品。他们常常不知道同级评审或审查为何物，也不知道评审究竟为按时交付高质量的产品做了什么奉献。我曾经遇到一位有制造业背景的质量经理，他是审查的反对者。他认为审查是制造业中产品人工查错这种质量实践的过时产物。当他明白通过软件审查能尽早查出软件错误，从而大大提高质量，他的抵触情绪也就随之消失了。管理者需要了解同级评审及其对整个组织的影响，这样他们才会将评审活动安排在工程方案中，为评审分配资源，并将他们对评审的承诺传达给小组。很显然，如果不做评审方案，评审也就不会被执行。管理者还必须重视同级评审中人际关系。请时刻警惕大家熟知的文化杀手，例如那些挑选某些开发人员以对他们的工作进行侮辱性评审“惩罚的管理者。如果没有来自管理层对同级评审的实实在在的承诺，那就只有那些意识到评审重要性的人才会切实地实施同级评审。对任何工程实践的管理承诺不能仅仅停留在口头许可或允许团队成员去实践上。下面列出了同级评审的 ll 项管理承诺。 同级评审的 11 项管理承诺1.向开发、实施和维持高效的评审过程提供资源和时间。2.为评审实践设置策略、期望值和目标。3.工程即使处在进度压力下，也要坚持进行评审。4.确保工程进度，包括评审时间。5.向评审参与者提供培训时机，让他们能亲身参与培训。6.决不要根据评审结果去评估个人业绩。7.拥有愿意参与评审并有责任心的评审人员。8.公开表扬能率先采用评审的人，以鼓励他人。9.和那些质疑评审的必要性的其他管理者和客户进行交涉。10.尊重评审小组对文档质量的评估意见。11.要求关于评审的进展、开销和获益情况的报告。为了说服管理者实施评审，你应当从管理者的角度来分析什么样的结果对成功是至关重要的，从而阐述你的观点。有些人对公开发布的数据很信服，但还有一些人却希望从本组织内部的试用中看到切实的成效。还有一些管理者，他们对逻辑和数据论证都不屑一顾，只是简单地说：“不！在这种情况下，记住我的一条根本的软件工程文化准那么“永远不要让你的上级或客户说服你做一项糟糕的工作。同时鼓励你的同事无论如何要进行评审可能要悄悄进行，以防止过度激怒了你的上级 。当你的上级希望用同级评审中收集的数据来评估作者的业绩时，会导致一种危险的局面Lee l997 。软件度量决不能用于奖励或惩罚个人。在评审过程中收集数据的目的是使你更好地了解开发和质量过程，从而改良那些运行得不好的过程，并且跟踪过程变化带来的影响。使用在审查中发现的缺陷的数量来评估个人是典型的软件工程文化杀手。它将导致测量功能紊乱，从而促使人们朝着偏离预定目标的方向前进Austin l996 。我最近收到一位质量经理的来信，他所在的公司已成功实施审查两年。他讲到，他们公司的开发部经理近来刚宣布要用审查结果的数据作为工作产品作者业绩的评估依据。在一次评审中发现的错误如果多于 5 个，这将对作者不利。自然，这样一来，开发小组的成员感到非常紧张。这也向员工传递了一个错误信息，即审查的目的是为了惩罚犯错的人，或者是为令人为难的工程找替罪羊。对评审数据的这种错误使用会导致许多功能混乱的结果，其中包括：1.为了防止惩罚，开发者可能不会将他们的工作产品交付审查。他们也会拒绝审查同事的工作以免使别人受到惩罚。2.在审查过程中，审查者可能不会直接指出错误，相反他们会事后告诉作者，这样他们就不会得罪作者。另外一种可能是开发者在这种带有惩罚性质的评审之前会事先进行一次“预评审来非正式地过滤出一局部错误。这破坏了公开查错的审查特征，也歪曲了从屡次评审中跟踪的度量。3.审查小组可能会争论某个问题是否真正是一个缺陷，因为缺陷不利于作者，而论点或简单的问题那么不会。这可能会掩盖真正的缺陷。4.审查小组的这种文化气氛可能会使大家将尽量少地找出错误作为心照不宣的目标，而不是尽量地检查出更多的错误。这会导致在没有减少花费的条件下降低了审查的价值，从而降低了审查的投资回报。5.作者可能会为了减少在每次审查过程中找到超过 5 个错误的可能性，而将产品分成多个局部进行屡次评审。这将使评审过程耗时而又效率低下。这是一种不正当的手段，为声称你的工作已经被审查而尽可能少做，没有正确地使用评审技术。使用审查数据来评估个人业绩，这些潜在的问题提高了审查的风险，加重了我们犯的错误，并使小组成员互相敌视。它鼓励参与者操纵评审过程来使其免受其害。如果我是处于这种情况下的一位开发者，我会建议管理层让该组织的同级评审协调者参见第 l0 章对屡次评审所收集的数据做统计分析，使得缺陷数量与具体的作者没有直接联系。如果管理层坚持使用缺陷数量来评估工作业绩，我将拒绝参与审查。管理者可能要求开发者将其工作产品交与别人评审，也可能要求开发者评审别人的工作产品，但是出色的管理者不需要通过缺陷数量来判断谁的奉献最大，以及谁的能力较低。当一个组织引进审查度量时，管理者往往会快乐地宣布：“这些数据将有助于衡量我们工程师的业绩。在审查冠军向他解释软件度量的哲理后，管理者同意不再只看个人审查的数据。他当众讲到要将审查过程作为一种工具来帮助工程师开发出更好的产品。他告诉工程师，他不会看重个人的审查测量值，因为他感兴趣的是软件工程过程的整体效率。这样，这位管理者周到的解说消除了该组织成员对审查测量的抵抗情绪。2.2.3 为什么人们不愿意实施评审为什么人们不愿意实施评审既然同级评审如此的好，为什么还有人没有使用它？没有使用评审的原因包括缺乏评审知识、存在文化问题，以及仅仅是不愿改变等，这些常常是借口。如果评审尚不是一个组织内标准活动的一局部，那么当了解其中的原因后，你就能知道必须作出什么改变才能使评审获得成功。许多人不理解同级评审究竞是什么，为什么值得做，非正式评审和审查有什么不同，以及什 么时候、怎样进行评审。适当的培训能解决这些问题。还有一些开发者和工程经理觉得，他们的 工程没有大到或者重要到非得进行评审的程度。然而，评审使任何一项工作都能受益于外界观点。另外，一些实践者始终认为软件测试比人工检查更有效，这种错误观念也会使他们避开评审。长期以来，测试一直被认为是软件开发中的一个重要活动。整个部门都要参与测试，并制定出工程的测试进度，为测试分配各种资源。在还没有彻底认识到同级评审益处的组织里，会缺少一种类似的文化需求和进行评审所需要的根底设施。同级评审的最主要障碍来自开发者没有意识到他们已经犯了多少错，因此他们也看不到查找和减少错误的必要性。许多组织在开发过程中不进行信息收集和总结，也不将一些有关质量的根本数据比方测试或者用户发现的错误数量拿给所有的小组成员看。当一个人将自己的工作拿给别人详细审查时，他可能会认为自己的隐私受到了侵犯。这种想法正威胁着一些人，这就是为什么企业文化必须强调评审的价值的原因，应将它视作一种提高质量和生产率，支持协同工作，并不进行工作评价的工具。从前所经历的不愉快的评审会造成极大的文化障碍。由于害怕缺陷被发现后可能遭受管理者的惩罚和公众的奚落，作者往往不愿意让别人检查自己的工作。当评审实施得很糟糕时，作者又会感到是他们自己，而不是他们的工作遭到了批评，尤其当某些个人之间已经存在冲突时，其结果会更加严重。另一个文化障碍在于认为作者本人才最有资格检查他自己的工作。 他会认为“你是谁，敢来为我的工作找错？同样，让一个新手来评审一位经验丰富的、受人尊敬的开发者的工作也会有类似的反响“我算什么，敢对他的工作指手画脚？当采纳改良的实践时，传统的方法是让实践者观察什么样的经验角色模型应该做什么样的事情，而让监督管理者观察和培训新员工。然而在许多软件小组中，每个开发人员都有自己的一套开发方法，如果他们不愿意，他们是不会轻易改变工作方式的Humphrey 2001 。荒唐的是，许多开发人员都不愿尝试新的方法，除非该方法已被证明是有效的。直到他们自己成功地使用了这些新方法，他们才会真正地相信这种方法。他们不会轻易相信别人的话。接着，就是借口问题了。它常常表现为 NAHNot Applicable Here，此处不适用综合症Jalote 2000 。那些不想参与评审的人会花大量的精力去解释为什么评审不适合他们的文化、需要和时间约束。借口之一是自负地认为某些人的工作不需要评审。有些小组成员不愿意为了评审同事的工作而被打搅。 “我正忙着修改我自己的错误，哪有时间给别人查错。“难道我们大家不是应该自己做好自己的事情吗? “Jack 的程序有问题与我无关。还有一些开发者过分乐观地认为靠他们的软件技能已不需要同级评审。 “审查方法已经使用了近 25 年了，这种方法已经过时了，我们的高科技小组需要的是最先进的技术。有些人抱怨审查过程过分严格，这种观点是人们对实践过程中过分官僚主义的抵抗。事实上，纯粹根据流程按部就班的开发并未将长期的质量保证视为组织首先考虑的问题。这样的文化背景可能很难采用正式的同级评审，尽管他们可以采用非正式的评审方法。2.2.4 克服对评审的抵触情绪克服对评审的抵触情绪要建立一个成功的评审程序，必须解决知识结构和文化中现存的障碍，以及对改变所存在的抵抗情绪。如果人们愿意学习，缺乏知识的问题是很容易解决的。我的同事 Corinne 曾发现，在她的组织里最坚决的对抗者是那些过去做过非正式评审的人。他们没有正确认识到同级桌查只是同级评审的一种见第 3 章 。Corinne 便向他们讲述了将那些非正式评审方法正规化以及采用一些审查所带来的好处。一天的课程还包括审查练习，这使小组成员对同级评审有了一致的了解。该组织的管理者也参加了该课程，并做了评审的承诺，他对小组成员说：“对我而言这是非常重要的，值得花时间，对你们也是同样重要的。我需要了解评审以便更好地帮助它成功。在假设要处理文化方面的问题，那么要求你必须理解现有团队的文化，并知道如何才能更好地鼓励团队成员进行软件工程的改良实践BouLdin l989；Caputo 1998，Weinberg 1997，Wiegers l996a 。通常他们都持有什么样的价值观？他们对质量是否具有共识和承诺？上一次的变化是如何获得成功的，为什么会成功？他们为什么而奋斗？谁是小组的民意领导者，他们对评审持什么态度?Larry Constantine 描述了软件组织中四种类型的文化范式：封闭的、开放的、同步的和随机的Constantine l993 。封闭式的文化采用传统的分级授权。你可以基于 SEI 的 CMM能力成熟度模型 ，依靠管理层来驱动过程改良程序，从而将同级评审引入到这种封闭式的文化中。这种由管理层推开工程实施评审的方式在封闭式的文化中可能会取得成功，而在其他类型的组织中就不一定了。开放式的文化以创新、协作和民主决策为特征。开放式文化中的成员会对同级评审的优点进行讨论，并参与何时和怎样实施评审的决策。受人尊敬的领导者如果曾经成功地实施评审，他们会引导团队自愿采用评审。这样的文化可能更喜欢举行可以进行方案讨论的评审会议，而不是审查因为后者强调查找错误而不是纠正错误。同步式的团队是一个协调一致的团队，他们对现状非常满意。由于意识到了相互协作带来的价值，他们极可能已经在实施至少是非正式的评审。对非正式评审的习惯和满意使实施审查程序更为容易。高速开展的处于领先地位的公司常常会形成一种随机文化，人员高度自治，喜欢以自己的方式做事。在这种组织中，过去已实施同级评审的人会继续下去，而其他成员对评审可能就不那么耐心了，虽然当工程的严重质量问题让他们急得火烧火燎时，他们也会改变想法。无论你怎样描述你的文化，人们关心的只是新过程会给他们个人带来的好处。面对所提议的过程变更，较好的反响方式是问：“它对于我们到底是什么？有时候当要求你改变工作方式时，尽管团队作为整体可能带来巨大利益，但给你个人带来的即时回报常常很少。我不可能花 3 小时评审别人的代码就能得到 3 个小时的好处。但是，其他开发者却可能防止了以后 10 个小时的调试时间，我们也能尽早完成这个产品。表 2-1 说明了工程组的不同成员可能从评审中获得的好处。当然，用户获益更大，他们可以按时拿到更可靠的、更符合需求的、高质量的产品。用户满意度越高，商业利润就越高。表格 2-1 同级评审为不同工程角色带来的好处工程角色工程角色同级评审可能带来的好处同级评审可能带来的好处开发者减少返工时间提高编程生产率保证实现的是正确的需求从其他开发人员学到更好的技术减少单元测试和调试时间减少系统集成和测试时的调试有利于组员间构件和整个系统的信息交换开发负责人缩短产品开发周期减少效劳和客户支持的开销减少整个维护开销，为新开发工程腾出资源加强团队合作，提高开发的有效性对工程风险和质量问题有更深的见解维护人员更少的产品支持需求，从而减少维护工作更好的健壮性从而更容易修改工作产品符合团队标准工作产品的可维护性和文档化程度更好，更易理解和修改在开发过程中由于进行了设计和代码评审，增强了产品的可理解性工程负责人产品按时交付的可能性增强更早地发现质量问题通过团队成员的交叉培训减少人员流动带来的影响质保负责人在开发期间可以判断产品的可测试性缩短系统测试周期，减少重复测试在进行产品发布决策时可以使用评审数据培训产品质量工程师可以预测所需的质量保证的能力需求分析员及早纠正需求分析中的缺乏和错误由于评审时开发者和测试工程师的参与从而减少了不可实现和不可测试的需求测试工程师可以集中力量查找那些难缠的错误，因为产品初始质量就很好减少阻止继续测试的缺陷改良测试设计和测试案例从而使测试过程进行得更加顺利在评审期间，当那些对评审不屑一顾的自负的开发者展示其最终工作成果时，可能更愿意接受来自同事的赞扬和尊敬。如果有影响力的评审抵抗者终于意识到同级评审的价值，那么他们也可能会说服别人尝试评审。一位质量经理曾经遇到一位名叫 Judy 的开发员，这位开发员反对“耗时的审查。在被迫参与评审以后，Judy 很快发现了它的技术威力，成为了同级评审的头号皈依者。由于 Judy 对她的同事有一定的影响力，因此她帮助使其他人的态度由抵抗变为接受。Judy 所在的工程组最后还要求质量经理帮助他们实施更多的审查。鼓励开发者参与有效评审程序，也有助于鼓励他们尝试其他的软件质量实践。在另一个案例中，一位新雇用的系统设计师具有审查经验，他帮助新团队成员克服了对审查的抵抗情绪。该团队收集的评审数据使这位系统设计师更加确信评审的价值。2.3 2.3 同级评审的评审级别图 2-1 描述了一个组织的软件同级评审实践的成熟级别类似的级别可参见 Grady l997 。评审级别越高，它带给组织的价值就越大。通过比拟你可以测定组织目前的评审能力，并查看应该在哪些方面改良。图表 2-1 同级评审的成熟级别在最糟糕的情况下0 级 ，整个组织没有人实施评审。级别 1 有一个小小的提高，小组成员执行临时评审。或许这个小组的成员没有听说过同级评审，或者他们认为没时间实施同级评审，或者会因为某些原因认为评审对他们的工程不适宜而拒绝实施。级别 2 中，小组成员定期进行非结构化的评审。参与者可能没有意识到还有其他类型的评审方法。他们还没有采用公共的评审术语或过程，可能实行的是走查或其他非正式的评审方法，尽管实际上没有实施真正的审查过程，但他们却称之为审查。小组的评审是为了查找错误和交换知识。级别 3 中，工程组定期地实施评审。这些评审活动被参加到工程方案中，小组成员知道怎样实施结构化的正式的评审，例如审查。整个组织采用了同级评审过程，综合采用了多种评审方法，并使用了标准表格和错误检查表。你不必从最低级别开始，目标至少从级别 3 开始，将审查作为日常的工作。这将使你防止徘徊和满足于较低级别而错过了正式同级评审的许多好处。最成功的组织实行级别 4 的评审，它代表组织已转向一种新的软件产品开发范式。处在级别4 的组织已经建立了一个正式的审