关于代码审查

一.什么是代码审查

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

Code Review中文译作“代码审查”或是“代码评审”，这是一个流程，当开发人员写好代码后，需要让别人来review一下他的代码，我们可以审查代码的风格、逻辑、思路……，找出问题，以及改进代码。

因为这是代码刚刚出炉的时候，所以，这也是代码重构，代码调整，代码修改的最佳时候。所以，Code Review是编码实现中最最重要的一个环节。

Code Review原本是整个流程中不可或缺，且较为耗时的一个质量保证环节，虽省略之后给业务方造成单位时间生产效率更高的假象，

但低质量的代码，会把团队带入漩涡，滚雪球一样的技术债，会让团队付出巨额利息。

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

（1）code review可以通过reviewers的建议增进代码的质量，也能提高owner的编程态度；

（1）code review有利项目流转，可以让其它并不熟悉代码的人知道作者的意图和想法，从而在以后轻松维护代码；

（1）code review鼓励程序员们相互学习对方的长处和优点，同时可以达到知识传播；

（1）code review可以用来确认自己的设计和实现是清楚和合理的；

（1）code review帮助找到程序的bug和保证代码风格和编码标准；

 

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

个人的技能成长不再只依靠自己或技术主管的建议，整个团队对单人的成长都能起到帮助，成员可以获得别处无法达成的发展。

从而进一步促进整个团队生产力的提升，最终项目进度和品质都能得到很好的保障。

 

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

（1）时间不够问题：业务倒逼工期，时间太紧，连coding都勉强，以上线为目的。解决方法：其实这不是CodeReview的问题，这是需求管理与项目管理的问题；

（2）需求变化问题：需求变得快，代码的生命周期太短，所以都写一次性烂代码。解决方法：临时代码不是单独存在的，会影响长期在用的代码，会影响长期稳定的技术团队。

（3）人员态度问题：不想精益求精，干活交差为主。解决方法：那么更需要Review来保障质量和促进上进了。

 

前提条件：

（1）统一的标准：没有评审标准的评审是混乱的；

（1）只实施于高价值模块：关注在核心系统代码、重用的组件等对质量有高要求的模块，而快速抢占市场的迭代型项目可在交付后再补Review；

（1）Reviewer奖励机制：reviewer的评审会占用工作量，是项目质量的保证者，贡献者，应建立适当鼓励机制与每月绩效关联；

（1）代码充分注释：要求核心代码，加上充分的业务注释、逻辑注释，以便reviewer更易理解代码思路；

（1）先跑CodeStyle检查工具：不应该把人工CodeReview的精力放在指出代码样式和规范上，所以代码请先用插件跑一遍CodeStyle自行检查与修改；

 

二.实施代码审查

建议有2种做法：

方法一：代码评审会议，称之为Code Review Meeting，就是将团队成员都组织起来开会，让代码Owner上去讲自己代码的实现和思路，其它人发表意见和进行讨论。

方法二：一对一评审，称之为Single Review，就是项目owner提交代码之后，让reviewer在空闲的时候帮忙评审代码，并且写出批注，owner收到批注后，进行修改或者回复。

              但注意这里的reviewer并不是只有技术主管或架构师之类的才能做，代码质量监管仅仅靠架构师是不够的，需要所有经验丰富或有专长的同学参与其中。

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

1、Review Meeting

优点： 

（1）团队内新技术/新观点的交流Meeting、项目开发思路、解决方案讨论，偏头脑风暴式；

（2）各类项目都适合进行；

缺点： 

（1）依赖于主持者（项目Owner）的素质、时间成本高（为会议上所有人时间的总和）；

（2）集体评审的代码行数有限；

 

2、Single Review

优点： 

（1）更偏重与具体的代码评审，人员分散参与，评审代码行数有保证；

（2）时间自由，Reviewer什么时候进行评审时间可自控；

缺点： 流程稍复杂，只适用于重要项目或核心模块；