如何举行一次高效的软件代码评审会议？

如何举行一次高效的软件代码评审会议？作者：uahoo

 

 

 

许多软件公司中，程序员是被代码缺陷驱赶着前进，程序员的工作节奏就是：编码、交付、修复缺陷、再交付的循环中... … 。在零碎的缺陷面前，程序员长期单独作战，无从全面了解设计与架构，也无法分享经验和获得团队的帮助与认可，他们情绪开始低落，知识结构也逐渐陈旧，开始死气沉沉。

代码评审(code review)是提升程序员士气、激发热情、增强沟通、提高代码质量的有效方法，应该成为软件开发组织中常用的缺陷排除手段。

 

常见的评审包括管理评审、技术评审、软件评审。软件评审的正式形式是软件审查（software inspection）。非正式形式有许多种，包括代码评审（code review）、代码走查（code walkthrough）、捉对编程（pair programming）、肩头评审(over-the-shoulder)、桌面检查(desk check)等。

代码评审是软件评审的非正式形式之一，但是有一定的规范要求。我们在编码过程中可以灵活采用，如果能坚持使用并注意采集度量值，也可以进行过程的量化管理与分析。

 

下面用问答的形式介绍一次高效的代码评审如何举行。

什么样的代码参加评审？

 

• 不是全部代码都要评审；

• 如果代码只能由团队中的某一两个人能明白、维护时；

• 如果代码对问题的实现比较抽象或者在算法上比较精妙时；

• 代码中某个对象、类、API在使用时有困难，含混时；

• 新手的代码或者采用新开发工具、开发语言编写的代码；

• 如果某些代码很关键，运行时不能出现任何错误的代码。

 

 什么样的人参加评审？

 

• 选择一个3-10人的评审团队；

• 团队成员要有技术背景，能够阅读和理解被评审的代码; 

• 选择一个主持人；（主持人有足够的技术背景，能客观地评价；控制会议、管理批评-不能让批评成为攻击。）

• 作者和其他参观者。

 

一次典型的代码评审是如何互动的？

 

 

• 评审会前散发材料 ，要提前散发，并确保代码被阅读了；

• 评审会上作者介绍代码，并不是逐行读代码，而是简单描述代码功能，当有人不理解代码的用处或者有疑问时，作者给出解释。

• 评审现场发现的缺陷只记录不修复，当检查者发现代码缺陷时，主持人只是记录在日志上，不允许立即修复它，而只是标识问题，直达所有代码评审完成，缺陷在会后被修复。

• 不陷入解决问题的细节，在代码评审会议中，主持人特别注意不能把会转向解决问题的议程中，工程师喜欢解决问题，导致陷入细节和长时间讨论问题分析，这些讨论有价值，但不属于代码评审，导致发现代码缺陷的效率将降低。

 

代码评审如何处理缺陷？

 

• 评审现场不允许修复缺陷，只允许-重构（refactor），通过现场重构代码，使得代码更加可读，可以标识额外的缺陷。

• 评审会后，代码作者修改直至关闭所有问题。要保证所有问题被修复并被评审者确认。

 

代码评审单有哪些内容需要考虑？

 

• 可读性；    代码是否清晰可读？程序员是否不必要的复杂化了代码？

• 可维护性； 其他工程师可否维护该代码？文档和注释是否正确？

• 正确性；    代码是否实现了功能？算法是否得当？

• 可靠性和健壮性；     代码是否容错力？异常情况如何处理？

• 安全性；代码在非授权访问，恶意使用，非法修改上如何处理？

• 扩充性；当负载、用户、数据、输入等增长时，代码是否是系统扩充的瓶颈？

• 重用性；本代码能否被其他应用使用？

• 效率；代码是否有效地使用的系统资源？并能被优化？

 

一场代码评审会议需要多少人时？

 

• 一般代码行数不多于400行；

• 每次评审会议不超过2小时；

• 评审团队中需要4~5人评审会前花费1-2小时阅读代码及准备评审；

• 评审团队中需要4~5人花费1~2小时参加代码评审会议；

• 一般统计评审效率是每小时预审代码约200行；评审会议上每小时评审100-150行代码

• 句统计平均每次代码评审花费约20人时。

 

 

如何评价代码评审的效率和效果？

 

• 代码评审效果差的主要原因有两个,评审内容太分散和评审过程不够严肃。如果评审活动不严肃，将浪费很多时间，而且没有回报，或者大家把它作为例行工作，敷衍了事。

• 评审时，技术主管事先约定规定效率基准，如java类代码，评审前阅读代码的效率是每小时160-200行代码，评审时每小时需要评审110-150行代码，

• 评估代码评审的效率时，常用3个指标测量，评审前的代码覆盖率，评审时的代码覆盖率，千行代码缺陷密度。评审前的代码覆盖率用于考核评审的准备工作，确保评审前，被评审代码被阅读和了解。覆盖率一般用每人时阅读的代码行表示。缺陷率一般用千行代码存在的缺陷数表示。

• 针对某一类开发语言的代码评审，累积12次评审，或者执行代码评审3个月以上的，就可以针对每次统计的结果，进行效率评估和评审流程的改善。

 

评审的好处？

 

• 在发现早期需求、设计、测试计划和用例的缺陷中，相对于测试，评审被逐渐公认是最有效和廉价的方法。

• 通过评审，团队中得经验和智慧被充分利用；

• 通过评审，让团队有参与感、工作被认可感、成就感；

• 通过评审，提高团队成员的进步，提高团队预防缺陷的意识，建立高效技术团队

 

代码评审工具有哪些？

 

• 最简化的形式  ;web或者客户端的diff工具，如Subversion用户可以使用Websvn；TortoiseSVN在小组内实施代码评审。

• 轻量级代码评审工具; reviewboard;

• 商业代码评审工具;  结合较为规范的流程和度量工具，可以采用商业化工具如Crucible ；

 

资料索引：

 《Software Project Management in Practice》

 《Applied Software Project Management 》

 《Pragmatic Software Testing: Becoming an Effective and Efficient TestProfessional 》