如何做好代码审查？Code Review Meeting还是Single Review

Code Review是提高开发团队技能以及保持团队迭代更新最佳的实践方法，也是代码质量管理中一个非常有效的方法。

---

什么？你不知道什么是Code Review？

Code Review中文译作“代码审查”或是“代码评审”，这是一个流程，当开发人员写好代码后，需要让别人来review一下他的代码，我们可以审查代码的风格、逻辑、思路……，找出问题，以及改进代码。因为这是代码刚刚出炉的时候，所以，这也是代码重构，代码调整，代码修改的最佳时候。所以，Code Review是编码实现中最最重要的一个环节。

我们真的需要做CodeReview吗？

Code Review原本是整个流程中不可或缺，且较为耗时的一个质量保证环节，虽省略之后给业务方造成单位时间生产效率更高的假象，但低质量的代码，会把团队带入漩涡，滚雪球一样的技术债，会让团队付出巨额利息。

1、保证项目质量、提高代码可读性

• code review可以通过reviewers的建议增进代码的质量，也能提高owner的编程态度
• code review有利项目流转，可以让其它并不熟悉代码的人知道作者的意图和想法，从而在以后轻松维护代码
• code review鼓励程序员们相互学习对方的长处和优点，同时可以达到知识传播
• code review可以用来确认自己的设计和实现是清楚和合理的
• code review帮助找到程序的bug和保证代码风格和编码标准

2、加速个人成长、突出团队价值

个人的技能成长不再只依靠自己或技术主管的建议，整个团队对单人的成长都能起到帮助，成员可以获得别处无法达成的发展
从而进一步促进整个团队生产力的提升，最终项目进度和品质都能得到很好的保障

那为什么有些人偏偏不愿意进行CodeReview呢？

1. 时间不够问题：业务倒逼工期，时间太紧，连coding都勉强，以上线为目的。解决方法：其实这不是CodeReview的问题，这是需求管理与项目管理的问题
2. 需求变化问题：需求变得快，代码的生命周期太短，所以都写一次性烂代码。解决方法：临时代码不是单独存在的，会影响长期在用的代码，会影响长期稳定的技术团队。
3. 人员态度问题：不想精益求精，干活交差为主。解决方法：那么更需要Review来保障质量和促进上进了。

好吧，既然这么好，那是不是任何团队都合适实施呢？

当然不是，你团队中的项目得满足以下前提条件：

1. 统一的标准：没有评审标准的评审是混乱的
2. 只实施于高价值模块：关注在核心系统代码、重用的组件等对质量有高要求的模块，而快速抢占市场的迭代型项目可在交付后再补Review
3. Reviewer奖励机制：reviewer的评审会占用工作量，是项目质量的保证者，贡献者，应建立适当鼓励机制与每月绩效关联
4. 代码充分注释：要求核心代码，加上充分的业务注释、逻辑注释，以便reviewer更易理解代码思路
5. 先跑CodeStyle检查工具：不应该把人工CodeReview的精力放在指出代码样式和规范上，所以代码请先用插件跑一遍CodeStyle自行检查与修改

好了，我一切准备就绪了，具体怎么实施呢？

我建议有2种做法：

• 方法一：代码评审会议，我称之为Code Review Meeting，就是将团队成员都组织起来开会，让代码Owner上去讲自己代码的实现和思路，其它人发表意见和进行讨论。
• 方法二：一对一评审，我称之为Single Review，就是项目owner提交代码之后，让reviewer在空闲的时候帮忙评审代码，并且写出批注，owner收到批注后，进行修改或者回复。但注意这里的reviewer并不是只有技术主管或架构师之类的才能做，代码质量监管仅仅靠架构师是不够的，需要所有经验丰富或有专长的同学参与其中。

那Single Review与Review Meeting根本上哪些不同呢？

一、Review Meeting

• 优点：
  
  • 团队内新技术/新观点的交流Meeting、项目开发思路、解决方案讨论，偏头脑风暴式；
  • 各类项目都适合进行；
• 缺点：
  
  • 依赖于主持者（项目Owner）的素质、时间成本高（为会议上所有人时间的总和）；
  • 集体评审的代码行数有限；

二、Single Review

• 优点：
  
  • 更偏重与具体的代码评审，人员分散参与，评审代码行数有保证；
  • 时间自由，Reviewer什么时候进行评审时间可自控；
• 缺点：
  
  • 流程稍复杂，只适用于重要项目或核心模块；

以前我们团队每周只进行 Review Meeting，从会议产出和面谈反馈来看，确实有一些的作用。但也不可否认的是，其中是有些弊端的，例如Meeting时评审的代码量很有限，且一些细节问题不容易暴露等等，但这却又是项目质量管理的重点。

那怎么办呢，后来也引入了Single Review，采用Review Meeting与Single Review相结合的模式。
即每次代码提交后，针对代码的变更进行Single Review，然后每周进行一次Review Meeting。

Single Review的主要流程

（我这里推荐使用facebook开源的phabricator工具，后面附图）：

1. 开发者user1在使用SVN提交核心代码时，在comment中添加Reviewer（向Reviewer提起代码审核请求，例如：Auditors: user2, user3，all）
2. 开发者user2、user3……收到系统发来评审请求邮件，登陆web进行评审，并可在不同的代码行处标注出修改建议和疑虑，最后提交评审
3. 开发者user1收到评审意见邮件，进行处理代码修改，重新提交评审，直到user2、user3……批注评审通过，代码才可交付测试

参考图：

---

更多文章，请关注我的微信订阅号：