CodeReview的本质分析

背景

代码评审（CodeReview，简称CR）作为很多研发团队的标准化部分被广泛使用。听到有很多工程师在代码评审时有这样一些疑问：

1、代码评审要达到哪些目标？

2、哪些方面是我应该评审的？哪些不是？

3、别人有没有认真的评审我的代码？如何让别人评审代码更容易？

今天咱们一起使用3W方法来透过问题看本质。

What

先来看看两个看似不相关的概念：什么是CI和CD。

Continuous Integration：持续集成，简称CI，是软件开发周期的一种实践，把代码仓库（Gitlab或者Github）、构建工具（如Jenkins）和测试工具（SonarQube）集成在一起，频繁的将代码合并到主干然后自动进行构建和测试。简单来说就是代码编写到提交到主干的过程。

Continuous Delivery：持续交付，简称CD，是在CI的基础进行了扩展，在CI环节完成了软件构建和测试工作并形成了新的版本，那么接下来就要进行交付，而这里的交付并不是交付到生产环境，而是类生产环境（STAGING），我们可以理解为灰度环境或者预发环境，进而接受部分真实流量的测试。简单来说就是主干上的代码到生产发布中间的自动化检查部分。

CD还有另外一个名字：Continuous Deployment：持续部署，它是在持续交付的基础上打通最后一公里的工作，就是把手动部署到生产环境的方式升级为自动部署。谷歌的一些开源代码就是采用这种方式部署的，第一次自己的代码被采纳的时候，对他们的自动化能力还是挺震撼的。

咱们先来说CI的意义价值(以下为我同事的总结，内容是借的)：

1> “快速失败”，在对产品进行自动化验证，并快速响应

2>减少风险，降低成本

3>将重复性的手工流程自动化，让工程师更加专注于代码

4>提高项目的能见度，方便团队成员了解项目的进度和成熟度

5>增强开发人员对软件产品的信心，帮助建立更好的工程师文化

CodeReview是CI的一个环节。自然要以CI的意义价值作为目标。控制的方法是设置一个卡点，只有评审通过的代码才能合并到主干还是分支上(取决于使用的是基于主干开发还是分支开发)。

Why

CI的原则是尽量使用自动化，CodeReview则是强烈需要人工介入的部分。为什么这么做呢？

1>避免设计理解偏差

经常有这种体会：自己作为设计者觉得已经将方案给开发人员传达的很明白了。并且开发人员自己也说明白了。但是让开发人员来复述，却多少会发现和自己想的不同。

下面密密麻麻的都是我为了一个总代码不算单测不超过500行的小优化做的，从整体到部分，自己觉得用活动图几乎覆盖了每一行代码：

连最简单的接口，源码几乎可以照抄旁边的的Service接口，还有下面的活动图：

也很有可能最终看到代码和自己想的不一致。而且实际中概率很高。完美的诠释了帕累托图的本意：二八原则。80%的都不一致。

2>知识传播

发现不一致，code review中间沟通，探讨的过程是相互学习的过程。我非常喜欢这一过程。但是鉴于每到code review，我的表情都非常凝重。好吧，看起来不只是凝重，所以估计被我review的同学看不出来我是欢喜的。

、

3>检查逻辑正确性

一旦线上出了问题，后悔、不甘……付出的代价和对应的精力不只是十几倍的差别。线上出现小问题，我一般反而特别急于下班，能早回就早回了。不是逃避，而是在哪里脑子都在思考、反思。不如回家躺床上思考精力更集中一些。

How

1>找对人

结对编程这个名词流行好多年了。但是现代对代码质量要求、线上稳定性要求都很高的这几年，优势才慢慢体现出来。因为结对编程，这两个人对代码逻辑都是了解的。找个不了解的人做code review，要不就发现不了问题。发现了也多半是技术性或者风格性的问题。而真正重要的逻辑问题往往发现不了。

这里提示一点哈，不知道会不会有同学对结对编程还停留在一个人写代码，另外一个人要在旁边盯着这个层面。设计、代码都是双方一起交流沟通过，评审过的就可以啦！

2>用对法

code review的同学一定要有checklist，避免遗漏重要检查点。下面是我整理的checklist：

• 注意文件是否有因为测试而进行的注释

• 注意单测覆盖率是否增加或者持平
  

• 是否缺少必要的注释

• 使用velocity模板：vm、xml和properties三者需要同时修改
  

• 一次代码提交不允许提交多个功能，单个功能可拆分成多个子功能分别提交
  

• 修改范围必须是本次功能涉及的范围，其他不允许修改，哪怕删除一个空行
  

• 除非新类或者类的所有功能全部进行了修改，否则不允许整个类全局format
  

• 所有的代码修改必须有单测，如果原来没有覆盖到这个分支或者对修改没有相应的断言必须补充，哪怕修改的是日志打印。日志打印可通过将打印日志加到单测类注释中手动对比实现，注释必须提交

• façade的POJO必须序列化

3>讲原则

上面checklist中很多内容比如先和其他人约定好。比如：一次代码提交不允许提交多个功能，单个功能可拆分成多个子功能分别提交。约定好的就只能照做。否则别人写完再提出来，code review和被review的同学都不舒服。情绪控制不好，反而容易写出糟糕的代码或者犯错。

往期推荐

和真正的程序员在一起是怎样的体验

编程十年的十种武学境界

技术境界的二三四

架构师之路-https底层原理