什么是code review

其实，code review 翻译过来就是 代码复查亦或叫做代码评审

代码评审是什么

为什么没人做

Code Review 在国内一直算个痛点，明知道是个好东西，就是用不好。 要么是制度问题，要么是流程问题，要么是观念问题，据我了解，国内 Code Review 做得又好又有效的，不算多数。 我在一家外包公司工作过，并试图推行过 Code Review。 但是结果却是无疾而终，不知道是不是咱们中国程序员都不大喜欢看别人代码，并且也不喜欢别人看自己的代码并提出改进意见呢？

从零到一

从零到一是非常困难的，国内之前没有 Code Review，想要去做，其实就是去模仿一个好的体制。 但是这并不是一件容易的事。因为别人的体制，始终是别人的。 就比如说美国的这个宪法，它有多强我们都知道，立宪这么多年了基本上就没有改过。 别的国家试图去抄美国的宪法，怎么着都没有办法实现。因为这样的体制与人、环境、观念息息相关，并不是放在哪里都可以的。

怎么做

流程和规则

我采用的是Pull Request（PR）模式来做Code Review。 Pull Request工作流不懂的自行百度

Pull Request(PR)简单的说就是你没有权限往一个特定的仓库或分支提交代码，你请求有权限的人把你提交的代码从你的仓库或分支合并到指定的仓库或分支。 由于PR需要有权限的人确认，所以非常适合在这个过程中做Code Review，是否接受或者拒绝就取决于Code Review的结果。 在支持PR模式的软件里，每一个PR都有一个新增代码的对比（diff）界面。 代码审核者可以在线浏览请求合并的新增代码，并针对有疑问的代码行添加评论，通过这种方式来实现Code Review。 评论可以被所有有权限查看仓库的人看到，每个人都可以回复任何人的评论，有点像论坛里某个帖子的讨论。 这种模式是事后审核，也就是代码已经提交到了中心仓库，Review过程中频繁的改动会造成历史签入记录的混乱。 当然Git可以采用更改历史记录来解决这个问题，由于容易误操作，一般只在基础类库这类要求比较严格的项目上实施。

由于Git太灵活了，因此诞生了很多的Git流程，用来规范Git的使用。 常见的有集中式工作流、功能分支工作流、Gitflow工作流、Forking工作流、Github工作流等等。

但是我的办法就是大部分仓库只定义了2个主干分支，master和develop。

master对应生产环境代码，所有面向生产环境的发布来源都是master分支的代码。develop则对应本地测试环境的代码。 绝大多数情况下，QA（测试）只测试develop分支和master分支的代码。

由于开发人员一般都是在一个团队内，所以我觉得没必要采用基于仓库的PR，而是应该采用的是基于分支的PR。 我们对主干分支的操作权限做了限制，只有特定的人才能操作，develop分支是项目开发Leader和架构师，master分支是QA。 有权限往主干分支合并的成员会按照约定的规则来执行合并，不会合并没有完成审核的PR。 上面这点其实蛮重要的，所以我们会对有权限合并的人有特别的约定，在什么情况下才能合并代码。 PR的发起人要主动的推动PR的审核，Leader也会密切关注PR审核的进度，在需要的时候及时介入。

我建议还要使用了Scrum里面一个很重要的概念：完成定义。 就是规定了我们一个任务的完成被定义为：代码编写完成，经过自测，提交的PR经过审核并且合并到主干分支。 也就是说，所有的代码被合并到了主干分支之后任务才算是完成，而被合并到主干分支必须要经过Code Review，这是强制的。

能有什么收获

1、短期内迅速提高了代码质量。

• 原因有几个，大家知道自己的代码会被人审核之后写得会比较认真。
• 理论上代码质量是由整个团队内最优秀的那个人决定的。
• 大家也能在Review的过程中学习到其它同事优秀的编码。

2、Bug数量迅速减少。

• 这点提高了整个团队的幸福感，大家不用经常被火烧眉毛。

3、团队成员对项目的熟悉程度会比较均衡。

• 新人通过参与Code Review能很快熟悉团队的规范。
• 代码不会只有个别人了解、熟悉，Bug谁都能改，新功能谁都能做。
• 对公司来说避免了人员的风险，对个人来说比较轻松，可以选自己喜欢的任务做。

4、改善团队的氛围

• Review的过程中会需要非常多的沟通，多沟通能拉近团队成员的距离。
• 并且无论级别高低，大家的代码都是要经过Review的，可以在团队内营造一个平等的氛围。
• 每个成员都可以审查别人的代码，这很容易激发他们的积极性。

总结

虽然有合适的工具支持会更容易实施Code Review，但它本身并不特别依赖具体的工具，除了Git。 原因是基于分支的PR流程依赖于大量创建分支，而Git创建一个分支非常的简单，所以PR模式+Git是一个很好的搭配。 审核通过以后会在BUG管理系统里面评论，QA同事没见到审核通过的评论就认为任务没有完成，拒绝进行测试。

像很多其他事情一样，code review 最难的就是迈出第一步。一旦开始，花在 review 过程的每一分钟都会很快被成倍地赚回来。如果你不在一个可以一下改变团队流程的位置上，那么至少可以和认同这件事的少数同事先开始实践，当价值开始体现的时候，相信其他人会乐于效仿。