代码评审的不可能三角

Code Review 是保证代码质量的重要手段之一，但许多研发团队中它经常因为各类缘由并未获得真正的落地。为何会这样呢？本文但愿用一个很是简单的观点来理解这个现象，并据此给出一点优化的想法。

观点

咱们的观点能够用一句话归纳，那就是代码评审很是难同时知足高覆盖率、强约束力和低开销这三个条件。这三个条件分别有什么含义呢？

• 高覆盖率，意味着评审须要覆盖项目中几乎全部的提交，而不是只评审新人的代码或者是批改暑假做业般的随机「抽查」。
• 强约束力，意味着在保证评审自己质量的基础上，评审中指出的问题都须要获得切实的解决，不然不该合并代码或发布正式版本。
• 低开销 (overhead)，意味着评审不该占用过多宝贵的开发时间，更不该像某些会议那样提起来就让人皱眉头。

论证

知足上述三个条件的代码评审，应该是每一位对代码质量有追求的开发同窗都不会排斥的。但为何咱们认为这样的评审可行性不高呢？简单地组合一下上述的条件，就不难发现矛盾了。

• 同时知足高覆盖率和强约束力的评审，时间是不可控的：为一些强调代码质量的开源项目贡献过 non-trivial 代码的同窗，应该都知道即使是一个简单的 fix，其 PR 均可能由于实现手法和维护者的理解有误差而长期保持在 Open 状态（俗称合不进去），更别说全新的特性与 API 了。
• 同时知足高覆盖率和低开销的评审，很容易流于形式：若是制度上约定必须对所有代码作评审，又不能耽误版本进度，那么这时候只要时间稍微一紧，评审就会变成平常回复 LGTM (Look Good To Me) 的走过场了。
• 同时知足强约束力和低开销的评审，很难覆盖到所有的代码库：一个版本中一般会有一些全新的特性。若是评审者并未参与这个新特性的开发，那么全量评审一个新特性的上千行代码，其难度跟打开一个没有读过的开源项目并立刻指出其中的 bug 差很少。

折中

若是上述三者不可得兼，咱们应该如何权衡呢？在目前的大环境下，多数软件项目快速迭代的性质与咱们对「早点下班」的渴望，使得低开销这一条件一般很难被牺牲。那么在覆盖率和约束力之间该如何取舍呢？让咱们回到「代码评审有什么做用」这个话题上吧。咱们知道代码评审能够：

• 减小代码中的暗坑
• 提升被评审者的代码质量
• 让团队成员熟悉代码

若是评审自己就形同虚设，上面这些好处天然也只是空谈而已。所以，咱们仍然很难放弃对约束力的要求。那么，如何改善这时覆盖率的问题呢？这里给出两点不成熟的想法供参考。

首先，来自 Google Subversion 团队的经验能够给咱们一些启发：他们将代码评审与即时通讯、会议、文档一块儿，视做团队中的沟通方式，而不是流程。这样，沟通方式之间就能够取长补短地提升团队效率。实际上，在评审全新特性时「读不过来」的问题，就能够经过设计阶段的文档来缓解：文档与评审一样是一对多的沟通，而且对文档中方案的讨论显然比直接讨论细节要更容易。一个须要 2 周时间左右开发出的全新特性，按照 问题定义 → 基本思路 → 实现概述 → 改进优化 的结构化方式编写的文档，其长度应该仅在千字左右，编写文档所需时间与开发时间应当不在一个量级，还可以节约在缺失文档时向其余同窗当面沟通该特性的时间（固然，对那种顺手就能搞定的需求也要求文档化，就有些繁冗了）。

另外，代码评审的覆盖率问题，还能够经过必定的提交约定来优化。在笔者翻译的 conventional-commits 规范中，每一次提交均可以经过形如 fix / feat / chore / refactor 的不一样类型来作区分，来达成细粒度的可读提交历史。那么，在评审的 Pull Request / Merge Request 粒度上，为何不能一样地应用该规范呢？若是咱们按照这种方式区分了 PR 类型，这里就有很多的想象空间：

• 能够首先将评审的资源集中在 refactor 与 perf 一类 PR 的评审上。
• 对于 feat 类型存在大量新代码的 PR，只需其提供了确保团队成员理解的文档，那么就只须要保证方案设计可接受，作保证代码风格、命名、路径等隐式约定一致级别的评审便可。
• 咱们能够选择性忽略测试阶段可能数量众多的常规 fix 类 PR，但对版本发布后补充的 hotfix 类 PR，仍然须要评审。
• 对不影响代码质量的 chore 与 doc 类 PR 能够忽略评审。

总之，代码评审是一种沟通方式，但愿它可以成为团队平常开发「文化」的一部分，而非束缚效率的死板流程。但愿本文的想法对一样被评审困扰的同窗有帮助 :)

P.S. 咱们 base 厦门的前端工具（编辑器）团队缺人中，有意戳这里了解详情哈。