谈谈代码评审(code review)

　　什么是代码评审(code review)? 根据维基百科的定义，代码评审是一种通过若干人员检阅源代码方式来进行的软件质量保证活动。根据软件工程的经典理论，代码评审应该是收益很高的活动，因其产生在Coding阶段（属于开发生命周期的早期），在开发生命周期越早发现问题，解决问题的成本越低。工程实践也能印证这个结论。 代码评审有以下目标：

• 提高代码质量和可维护性（可读性，一致性）
• 发现代码缺陷
• 知识经验传承
• 发现更好的解决方案
• 满足ＱＡ指导方针

　　本人根据针对网络上某代码评审最佳实践的公开文章谈谈自己的想法。

原则１：每次只评审小于２００～４００行的代码。

－－》　我的观点：这个只要是考虑到一次评审的代码过多，评审者发现问题的能力将大量缩小。如果一次评审过多代码，会对评审者带来智力和心理两方面的挑战。从智力上来说，抛开极少数智力超群者不谈，对普通人来说，一次评审更少量的代码更容易理解代码的意图（同时减少了与代码作者的沟通成本，提高效率）。这也是符合分而治之的解决问题方法论的。从心理上来说，一次评审过多代码会对评审者产生倦怠感，评审者主观上通常会降低评审的细致度。根据我的经验，如果某项软件开发任务代码量比较大，可将此任务分解为若干子任务。子任务的划分粒度尽量做到一周的代码提交量（提交的代码需要测试通过）。当然，子任务的划分是建立在良好的设计文档基础上，否则子任务划分的随意度比较高且工作量评估容易不准确。

原则２：代码评审速度应小于每小时３００～５００行。

－－》　我的观点：这条主要是考虑评审的细致度，细致度越高越能发现更多问题。换算一下，一个２０行的函数，评审时间应不少于２～４分钟。

原则３：检查清单（checklist）可以大幅改善评审结果

－－》　我的观点：检查清单对代码作者和评审者都有作用。对代码作者来说，可以在编码的时候就犯止犯类似的错误。对评审者来说，可以帮助评审得更全面，特别是找出遗漏的问题。检查清单可以定期更新，在评审过程中发现的问题都可以对照检查清单，看看是否需要添加新的条目。最新的检查清单需要在团队内公布，最好是放在一个固定的位置方便随时查看。这个检查清单可以考虑和编码规范放在一个文档，互为对照补充。

原则４：团队领导者应建立一种正面的评审文化，即应正面看待评审中发现的问题

－－》　我的观点：为什么需要完全正面的看待在评审中发现的问题？如前文所述，在代码评审中发现问题的修复成本非常低，所以发现越多问题越是好事。只有完全正面看待代码评审发现的问题，评审者才会有更大的动机会发现更多的问题。对于代码作者来说，在代码评审中发现问题，可以帮助自己修正错误的编码习惯和提高自身的编码能力。同时，完全正面看待评审发现的问题，能使得评审者和代码作者建立更为和谐的关系，更有利于发现更多问题。为了建立正面评审文化，领导者需要在团队中宣贯在评审中发现问题表明代码作者和评审者通过成功的团队合作提高了代码质量，领导者绝对不应将评审中发现的问题列入任何针对个人的考核因子。

原则５：轻量级的代码评审是有效率的和现实的

－－》　我的观点：软件工程理论中非常正式的代码评审一般要召集不同角色的工程师，通过召开会议来逐行审查代码并进行讨论。但是这种方式成本比较昂贵，较少有公司能够负担起这种人力成本。所以现今大部分公司都倾向于实施非正式的代码评审，一般是基于工具。最简单的非正式代码评审可以是基于邮件列表，缺点是无法很好的记录评审过程中的修改历史和沟通信息。幸运的是，现在有很多可以用于做代码评审的工具，包括商业的和免费的。

　　另外，我想再做一些补充。对设计的评审应该基于设计文档，在代码评审阶段去评审设计将会是低效的并且需要花费巨大的沟通成本。当然如果在代码评审阶段发现了设计的问题，需要回过头去重新修改＆评审设计文档。

　　综上所述，轻量级的代码评审对于业界大部分的软件开发组织都是一个很好的选择。是否在内部建立起正面的评审文化常常起决定性的作用。根据我的观察，是否进行有效的代码评审也基本上是区分二流软件开发组织和三流软件开发组织的一个明显标志：）