提到 Code Review（CR），就和单元测试一样，虽然一直在提倡，大家也都知道他的重要性，但是实践起来总是差点意思，有个说法是 CR 就和鬼一样，一直有他的传说，但一直没有见到过。本文梳理下团队目前在做的 CR 实践，做点沉淀。

01

目标是什么？

任何活动都有它的目标，CR 也不例外，对于 CR，团队给出的目标是：为了保证公司整体代码的健康状况随着不断迭代，始终保持一个较高的水平，希望通过规范化代码评审及其过程，可以提高代码质量、减少错误、促进团队合作和知识分享，提高软件开发的效率和质量。

从这个目标中，就可以看出 CR 的种种好处（其实大家都能看得到，只是无法保证落地）：

1. 统一代码风格：虽然实现一个需求有各种各样的方式，但统一的代码风格有助于团队间的沟通交流，也有助于快速分析确认问题，所以在 CR 的过程中，非常重要的一项内容就是统一代码风格，包含命名规范、循环规范、复杂度规范等，需要团队提前声明并达成一致。

2. 提升能力：“Talk is cheap, show me the code”，不论是参与评审代码的人，还是被评审的人，都会在一次次的 CR 中提升自己，因为 CR 的过程就是发现自己不足的过程。

3. 知识共享：在评审过程中遇到好的实现，就可以快速推广，遇到常见的问题，就可以提前避免，让个人的经验快速变成团队经验。我们的新人加入团队后，有件事就是查看过程的 CR 记录，了解团队的沉淀。

02

有效地保障机制

如上图所示，为了保证 CR 的持续落地，形成规范，团队建立了有效的机制来保障这一活动不走样，不流于形式：

1. 代码规范：通过学习《阿里 JAVA 开发手册》，结合团队自身的特点，重新定义的更有效的代码规范，并导入到 SonarQube 中，变成静态扫描规范，融入 CI 过程中，每次 Commit 必须通过增量扫描。

   1. 工具使用：除了 CI 的扫描外，还需要在本地进行一些常规的扫描，快速发现问题并解决问题，如 sonarLint 插件、P3C 插件等，在本地自行检查代码是否合规范
   2. 代码评审：双周举行一次线上/线下代码评审，至少一名技术委员会成员参与，重点关注代码规范、逻辑异常、代码优化、代码缺陷及性能风险等方面的问题，问题统一记录。
   3. 复盘交流：跟踪代码评审是否落地、发现问题是否及时修复。分享评审过程中的典型问题，共同学习和成长。

03

评审过程中的策略

在评审过程中，要特别注意不能把代码问题升级成为人的问题，组织者要特别注意引导和及时地提醒，在评审过程中，建议：

1. 不是每个人的经历都跟你一样： 有些东西对你来说是常识，但有些人可能并不知道，即使他们的能力并不差。你可以说这些东西是常识，但不要显露出嘲笑或高人一等的姿态。

2. 礼貌用语： 使用礼貌用语（比如 “请”）表示对代码提交者的尊重，特别是当你要他们在细节上做出一些调整（比如格式化）时。

3. 避免夸大： 简单一点，把你的顾虑和问题说出来，这样有助于你获得期望的结果。

04

成果展示

CR 在团队中的落地已经有一段时间了，这个活动将持续进行下去，目前发现的问题数如下：

可以看到，评审过程发现的代码缺陷和性能类其实并不多，更多的是集中在代码规范和代码优化上，这也符合对 CR 的预期。不能寄希望于 CR 能发现多少缺陷，因为这本身就是类似于静态代码检查。

代码评审记录表如下图所示：

05

CR 的积极意义大家都懂，如何落地取决于团队的负责的决心及团队成员对代码的自我要求程度。取决于你做不做。

共勉。