简介： 对于代码评审（Code Review）的文章也算是车载斗量了，代码评审也曾经是许多组织的标准化实际。不过，在许多团队在尝试代码评审实际时，却有如下的疑难：“政治正确”的代码评审流动到底有没有达到冀望的实际效果？给了我一大堆代码，到底该从哪里看起？哪些方面是我该评审的？哪些不是？他人有没有认真评审我的代码？如何让他人更容易的评审代码？这些问题都不是什么

对于代码评审（Code Review）的文章也算是车载斗量了，代码评审也曾经是许多组织的标准化实际。不过，在许多团队在尝试代码评审实际时，却有如下的疑难：

• “政治正确”的代码评审流动到底有没有达到冀望的实际效果？
• 给了我一大堆代码，到底该从哪里看起？哪些方面是我该评审的？哪些不是？
• 他人有没有认真评审我的代码？如何让他人更容易的评审代码？

这些问题都不是什么新问题，然而它是如此的广泛，而且经久不息的在不同的上下文中被提起，不外乎两个方面：

1，了解代码评审的外围指标，建设对于代码评审的正确预期。

2，理解代码评审为什么可能有效，并采取有针对性的实际来晋升代码评审的成果。

为什么要做代码评审

不少同学认为代码评审就是用来查错的，甚至心愿用代码的缺点数量来测验代码评审的成果。这低估了代码评审的价值。代码评审最实质的作用不是问题发现。除了代码评审，咱们有更多更好的伎俩来发现问题。 代码评审的作用更多是对于社会学的，是一种长期行为和组织文化 。

CR 是代码规范性的保障

编码者视角：良性的社交压力

你正在缓和的编码，交付工夫火烧眉毛。你的组织对代码的单元测试有一个要求：但凡新增的代码，必须有残缺的自动化单元测试。然而，这压力之下，你想给本人升高一点要求，不写这部分待的单元测试了，当前再编写吧，或者为了应酬工具的覆盖率要求，先写一点不那么有用然而却能带来覆盖率的测试（例如没有断言的测试）。

然而，一旦想到你的代码收回去将会有你的共事做 Review，有没有为方才的这种想法产生一丝丝压力？这种压力是良性的，它能给你带来一种即时的反馈，阻止你去抉择那些短期收益、长期损失的“投机”行为。如果没有代码评审这个环节，或者你就会真的“随心所欲”了，其实最终还是要为这种取巧行为埋单。

维护者视角：代码可读性的保障

有许多形式能实现同一个软件需要。有趣味的读者可自行搜寻“Hello World 的 N 种写法”。只管条条大路通罗马，然而，不同的路线代价是不一样的。小到变量命名，大到设计构造，如果你采纳的是一种不那么常见的做法，往往就是给给起初的代码维护者挖坑。这种保护流动可能产生在 1 个月当前，也可能产生在 1 年当前，甚至是更久之后。甚至那时候，作为作者的你，曾经不在这个团队了，曾经没有人能了解过后的软件为什么这样设计。

代码评审强制提前了这个反馈周期，代码编写实现之后，就立刻有了一位或多位读者，他们是这个代码的 Reviewer。所以，这段代码曾经在编码实现之后，立刻经验了可读性的测验。更现实地，如果组织曾经有了编码标准和设计规范，还能确保这段代码遵循了这些标准。如果这时候发现这段代码没有遵循标准，那更是坏事，它指向了 CR 的另外一个要害价值：常识流传。

CR 带来了常识流传和设计共识

你可能是一个团队的 Leader，正在为如何晋升团队成员的编程能力发愁。你心愿他们去读书，所以你介绍了诸如《整洁代码》之类的入门书籍，你还介绍了经典名著《设计模式》，还举荐了《畛域驱动设计》。你也心愿团队成员能了解产品的业务逻辑，所以心愿团队成员周期性的分享进行业务分享。

所有这些致力都很好。然而，也有可能你会被打击。一个月过来了，仿佛团队成员对命名标准都建设了概念，然而这怎么命名这件事上，大家并未造成共识。不少同学曾经理解了一些设计模式，然而有人适度使用模式，搞的代码臃肿不堪，有人则只晓得 singleton。团队成员为什么是实体对象，什么是值对象争的不可开交，没有人说得分明聚合是什么，应该什么场景下实用。

你真正不足的，是一个场景。形象的概念如果不落到具体的事件上，就很难造成共识。有人或者晓得海洋法系的“判例”，这是这法律层面造成共识的一种十分好的办法。代码评审，其实也是这造成判例：哪一类设计是正当的，哪一类设计是不合理的。通过针对具体的问题进行剖析，团队就会逐步造成设计共识，在过程中，对这些共识不那么相熟的新同学，也能够缓缓融入。

当然，CR 也能用来测验逻辑正确性

保障代码逻辑正确，是设计者的责任

为了不让 CR 被滥用并被寄托过高冀望，咱们在此首先申明一点：保障代码的逻辑正确，是设计者的责任。代码呈现来一个空指针谬误，到底是编码做的不好，是 CR 做的不好，还是测试做的不好？那首先必定是代码作者制作这个问题。把这个板子打在 Reviewer 身上偏心吗？或者，Reviewer 的确有责任发现这样的问题，然而，如果代码原本就谬误多多呢？如果一次性 Review 了 1000 行代码，基本看不过去呢？我能找到一大把的理由，来阐明为什么漏掉这么一个空指针谬误。

发现逻辑谬误的其余办法

你还有许多其余的办法来发现错误，它们的老本往往并不高，例如：

• 编写自动化单元测试
• 应用代码动态查看工具

无论是否存在 CR 流动，上述两点都是一名业余的开发者和开发组织应该鼎力提倡的行为。

代码评审的确也有谬误发现的价值

在上述两点的前提下，代码评审的确也应该用于发现错误 - 它实质上建设来一种冗余机制，通过多人来工作在同一段代码上，发现代码中可能产生的认知谬误（这对于单个开发者往往是很难发现的）以及忽略。

高效高质的代码评审

哪些因素妨碍了代码评审的成果

代码评审自身并不艰难，然而，如果思考到如下因素，可能就比较复杂了：

• 你可能对要评审对代码的设计上下文无所不知
• 你可能十分繁忙
• 你一下子收到了几千行须要被评审的代码
• …

实际操作倡议

小批量：每次 Review 的代码量要少

钻研发现，胜利的 CR 流动肯定是小规模的。例如，《Modern Code Review：A Case at Google》论文介绍说，Google 的 CR 流动中，有 35% 的 CR 仅仅批改了一个文件，90% 的 CR 批改的文件数在 10 个文件以内，甚至有 10% 的 CR 仅仅批改了 1 行代码。

代码量少的益处不言而喻：批改在哪里十分清晰，问题也会高深莫测。一次推给他人 1000+ 行代码，还想得到有价值的 Review，可能性微不足道。

当然，一次 Review 它代表的性能应该是有意义的，是残缺的，如果不是修复缺点，这肯定水平上也对开发者迭代地开发性能的能力提出了要求。

多批次：Review 要频繁产生

小批量必然导致了多批次。在微软 2013 年的一篇论文《iExpectations, Outcomes, and Challenges Of Modern Code Review》和前述的 Google 的论文中都提到了频繁 Review 的做法。其中，Google 的每周每 Developer 的代码变更中位数是 3 个，每周每 Reviewer 的 Review 中位数是 4 个。

疾速响应

当每次 Review 的粒度不大，Review 又比拟频繁时，疾速响应能力成为可能，也是必然的要求。在这个数据上，Google 的中位数是 4 小时。这个指标能够成为一个较好的参照。

找对人：适合的 Reviewer

谁适宜 Review 你的代码？选一个和被 Review 的代码毫不相干的人必定是不明智的。上面列出了一些潜在的候选人：

• 如果你的组织有 Owner 机制，Owner 应该是适合人选
• 和你工作在雷同上下文的共事
• 近期批改过雷同代码的共事
• 比你更资深的程序员，心愿失去他们的业余反馈

当初曾经有一些工具，可能依据上下文举荐 Reviewer，这也为抉择适合的 Reviewer 提供了便当。

适合的工具

疾速响应、高质量的 Review 离不开古代工具。古代的 Review 工具能主动集成进工作流，高亮变动，甚至能主动汇总变更。这方面曾经有许多古代的工具能够应用，还没有选好工具的读者，能够自行 google 搜寻。

思考结对编程

当咱们提到“小批量、多批次、疾速反馈“的时候，如果有过结对编程教训的同学，马上就会反映过去，这就是一种试图靠近结对编程的模式。

结对编程，独特编程的两位同学领有完全相同的上下文，不存在上下文切换的懊恼，没有不足工夫的懊恼，不须要借助额定的工具，反馈随时随地。事实上，在我的眼中，结对编程才是最好的 Code Review。

综合在线 Review 和线下 Review

在线 Review 应该是常态化的行为。思考到 CR 的”常识流传“价值，线下 Review 是无益的补充。有教训的团队，会周期或者不定期的组织线下 Review，这样能取得比在线 Review 更为宽泛的常识流传面，也能引起更为热烈的探讨和答辩，有助于造成更高质量的共识。

一些能够用来数字化的 CR 指标

研发行为的全面数字化，带来了一些有价值的数据洞察。如果工具反对，能够通过一些指标的观测，继续推动 CR 流动。咱们把一些倡议的指标和数据总结如下：

从 Author 角度：

• 单次变更的代码行数（次要指标）
• 变更的频度（参考）

从 Reviewer 角度：

• 响应工夫
• 评论数和回绝率

从 Reviewer 的个人角度，还能够发现 Author-Reviewer 之间的社群关系，也是一种有价值的理解常识流传的信息。

不要做什么：

CR 的实质是文化建设，强烈建议仅仅把 CR 的指标用作晋升指引，而不要用于和绩效无关的评估。无论是前述的几种指标，还是和 Review 的品质甚至是缺点相干的数据。

原文链接
本文为阿里云原创内容，未经容许不得转载。