谈谈代码评审(code review)

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

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

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

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

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

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

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

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

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

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

－－》　个人观点：为何须要彻底正面的看待在评审中发现的问题？如前文所述，在代码评审中发现问题的修复成本很是低，因此发现越多问题越是好事。只有彻底正面看待代码评审发现的问题，评审者才会有更大的动机会发现更多的问题。对于代码做者来讲，在代码评审中发现问题，能够帮助本身修正错误的编码习惯和提升自身的编码能力。同时，彻底正面看待评审发现的问题，能使得评审者和代码做者创建更为和谐的关系，更有利于发现更多问题。为了创建正面评审文化，领导者须要在团队中宣贯在评审中发现问题代表代码做者和评审者经过成功的团队合做提升了代码质量，领导者绝对不该将评审中发现的问题列入任何针对我的的考核因子。

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

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

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

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