前言
代码，是任何一项伟大产品的基本组成部分，是设计理念落地的地方，是技术的呈现和根本，是贯穿整个业务流程的支撑。
Code Review(简称CR), 首要目的是保证代码可读性，一致性，其次是设计讨论和知识分享, 既是一种项目质量管理方法，确保团队职能的稳定、安全、准确，也是一种技术团队的专属文化，是开发者之间特有的一种沟通方式，其机制是否健全是评价一个研发团队技术氛围好坏的重要参考。
在我们在团队内部一直提倡质量管理，并成立质量小组，在研发流程的各个节点进行质量管理的优化工作，并要求开发团队不能为了进度而节省MR流程环节，最终导致质量的牺牲。CR过程中要做到落地沟通，不能再是空对空的无代码式、纯理论式讨论，能够在实际问题中产生思考的碰撞，能够互相学习，能够互相提高编码水平，以期团队内每个成员都掌握团队里积累出来的最佳实践。团队在合并MR阶段通过相互进行Review的形式, 让团队开发人员在这个过程中学会高效阅读他人代码，提高代码质量，减少一些不必要的错误，并在团队内部达成了共识。最后希望该形式能在团队内慢慢形成一种良好氛围，每个人都能自觉去维护它。
—— GFE
前提
在一个团队做代码评审之前，团队成员间需要达成一个共识，制定一份合理的代码规范标准, 并确定基于此种形式的基本准则，比如我们会要求团队的CR不承担发现代码错误的职责而是承担检查规范代码风格和编码标准职责等，只有确定好前提，后面做的时候才有行为标准。另外我们针对技术也有两个不错的共识：一是学习是工作的一部分，不学习技术永远不能提高。二是事情需要先做成再做好，再还没有做成之前如果过度追求代码如何如何、形式如何如何，恐怕顾此失彼，得不偿失。
这是在我们进行第一次进行代码评审时，所确定的基调。
CR会在每次的研发周期中选择不同的开发人员进行，形式是邀请制的，当然也是不可拒绝的。
形式
我们团队在对CR制度的逐渐完善过程中，最终形成三类CR形式：
1.常规MR时候的在线交叉CR
这部分工作是在贯穿整个工作时间中的, 每个人既是Author(作者)又是Reviewer(评审者), 每次针对代码的改动, 都要经过最少两个Reviewer的Approve(同意)可以进行合并, Reviewer可以经过评审Author的代码学习到一些优秀的技术,规范等等, Author也可以经过Reviewer的评审避免一些大意的错误.
2.阶段性的小组代码评审会议(Code Review Meeting)
这个阶段的CR通常伴随着一些业务知识进行评审, 比如你正在开发一个系统的权限模块, 那就针对人员、角色、模块等等进行一系列的评审, 设计是否合理? 模块划分是否耦合? 消息机制是否完善? 可扩展性是否满足发展需要? 等等. 这块可以极大的提高我们在对系统架构设计方面的能力.
3.复盘时的重点CR
我们非常不希望进行这样的CR，因为复盘的CR意味着存在着一些重要的问题并产生了影响，但是机制仍然要有，而且还要进行相关的实践。复盘时的CR首先要明确问题的所在，因为这是一个团队的问题，到了这个环节就说明上面两个环节我们都没有做好，这时发现的所有问题都需要团队集体承担。
如果你想让自己的代码水平有所提高那你也要认真的评审其它人的代码，每个都可以分享他人的成果并从中有所学习，不论资历如何每个人都是团队的一份子，都有资格享受团队的成果和荣誉，当然未来有一天你的成果也会被团队所分享，但是如果出现什么状况，依然需要大家一起上一起扛，这样才是公平的工程师文化。
—— GFE
规范
版本迭代
日常开发中，我们的绝大部分时间都是花在这块的，也是CR中的重点环节。
这样一个长期开发的工作中，人都会不可避免的出现一些纰漏，而这些纰漏在另一个人眼中也许显而易见。
开发者根据 Develop 分支建立个人开发分支，每天自行 Merge Develop 分支代码；根据开发情况，定期向 Develop 分支发起 Merge Requests 请求，然后通知相关人进行 CodeReview，根据代码情况查看是否进行合并，合并与否都需要留下 comment。一般来讲，一个 MR 不宜过大。如果是大的 feature 改动，可以分成多个小 MR 分次提交。
MR消息通知与及时处理后面会专门讲解，我们已经投入使用几个月时间，可以整体提高CR、MR效率
紧急修复
开发者根据 Master 分支建立临时 hotfix 分支，根据开发情况，向 Master 分支发起 Merge Requests 请求，然后通知相关人进行评审，根据代码情况查看是否进行合并，合并与否都需要留下 comment，上线后相关开发者删除临时hotfix 分支。相信绝大多数团队也都是这样的分支管理规范， 当然这里不是重点，重要的是如何在紧急情况下如何保证上线的代码质量。
依赖于团队规范，每次提交的代码必须经过审核。允许合并的前提是至少有两个LGTM，并且没有其它正面拒绝的意见。
要求说明
1、任务完成才能提交MR，没看过MR、没评论意见不能通过。
2、MR应该最迟在一个工作日内被合并或者被拒绝。
3、MR在有严重问题（包括但不限于架构问题、安全问题、设计问题），太多问题，或者任务无效的情况下会被拒绝。
4、严禁一个MR里面有多个任务，除非它们之间密不可分，并且短时间内不能及时优化。
5、MR提交之后只允许针对Review发现问题再次提交代码，除非有充足的理由，严禁在同一个MR中再次提交其它任务的代码。
6、如果一次提交的内容包含很多Commit，请不要使用自动生成的描述。
7、请用简短但是足够说明问题的语言（理想是控制在3句话之内）来描述MR内容。
8、在常规流程中严禁不经过审核而直接Merge代码，如有需要直接指派给团队负责人根据情况决定是否可以进行紧急合并。
9、Code Review不能形式化，要将别人提交的代码视作自己将维护的代码。
10、审核过程中术语的使用参考并不限与以下参考.(文末付参考)。
邀请原则
1、在创建MR时，审核人一栏里必须填写“审核人”，并至少两人，只有这些人审核都通过，才允许合并。
2、“分配给”一栏必须选择“合并人”，只有审核人都通过后，"合并人"才可以进行"合并“操作。
3、除了“必需审核人”外，还可以有一些其它审核人，可以在审核人一栏里做为“邀请审核嘉宾”，默认按顺序从第三人开始就可以作为“邀请审核嘉宾”。
4、主干分支间的合并，如dev => master，test => master等，则需要把MR执行交给团队负责人进行操作。
意义
·交叉排查缺陷
绝大多数BUG都可以在代码层面被发现，甚至测试难以覆盖到的深层次BUG也可以通过团队成员相互审核而避免
· 提高代码质量
Code Review意味着开发者要接受团队成员的建议与监督，在完成功能的基础之上不断完善代码结构
· 建立团队意识
代码是团队财产，团队成员在相互分享，相互促进与改进中共同成长
CR体系
· Daily Code Review
开发者完成初步结构设计，或者完成一个相对完整的小模块都可以提交MR让团队成员Review。这项是最重要的一个环节，绝大多数问题应该在每天的CR中沟通解决，也就是功夫在平时。
· 需求Code Review
评估需求完成度，与其它需求的潜在冲突，增加对需求的理解。
· 上线Code Review
上线前Review，重点排查配置问题，安全问题，代码冲突。
· 复杂代码Code Review
业务复杂模块的Review，重点查看逻辑思维，代码注释，方便后期维护。
技术复杂模块的Review，在于提升大家对于技术实现的方法认同感。
· 重点代码CodeReview
每个迭代/双周/月度对具有代表性的代码集体走读，重点在于解决团队共性问题，讨论改进方法。
· 交付体现
每次CodeReview都需要有重点checklist的清单与交付物的体现(比如邮件)。
文化积累
通过多层次的Code Review体系，在团队中建立起集体认知：
· 代码是团队共有的技术资产，而不是某个人的私有属性
· 团队所有成员对所有代码的最终质量负责，而非某个人对某些代码负责
· 事情先做再做好: 完成功能只是事情的基础，代码需要持续改进以符合团队质量管理标准
· 良好的工程师文化是建立在交流、共享的基础上的
总结
Code Review体现的是团队对于代码质量的追求，对于团队内部协作的重视。
对于团队成员来讲，对于日常工作的钻研与打磨比偶尔一次的技术培训或分享更有学习价值。
说不定你今天Review的一段代码，之后就是由来你维护的。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
