资深工程师如何把关 Code Review?

先前我们曾写过 为什么要 Code Review? 如何做 Code Review? ，以及 为团队建立更好的 Code Review 原则与规范 两篇文章来谈 Code Review。

从职级的角度来看，第一篇文章主要是写给初中阶工程师，因为在初中阶段，工程师主要职责是参与 Code Review。而第二篇的主要受众则是资深工程师，因为资深工程师影响力扩及团队的标准与规范。

在这篇文章中，我们会延续资深工程师的视角来谈「以打造制度与文化的角度来看，资深工程师可以如何把关团队的 Code Review」。换句话说，不能只是自己做好审查别人的程序，而是要让团队整体的 Code Review 品质都能提升。

如果有意面试资深，或者资深以上 (例如主任工程师) 职位的读者，可以特别留意这篇文章谈的观点 (备注：如果你是初中阶工程师，则推荐可以看 [在线课程] 写出好维护的程序 (上) — 经典的程序设计观点 在线课，该课程协助建立审查他人程序时可以用的技术观点)。

资深以上的工程师如何看 Code Review

过去我们有收到一些读者询问，谈到自己所在的团队没有 Code Review 的机制。从资深工程师的角度来谈，这不是个问题，反而是个机会。假如你所在的团队还没有 Code Review 制度，从自己做起来导入，才能彰显资深工程师的价值。甚至假如你的职称还不是资深工程师，假如你能有效在团队中导入 Code Review 机制，在找下份工作时，把这点写在履历上也能用来佐证自己有做资深层级任务的能力。

更进一步说，资深工程师可以通过 Code Review 来消除团队的巴士因子(bus factor)。巴士因子是用「假如团队中最重要的人被巴士撞伤无法工作，这个团队是否还能继续如期运作」这个问题来评估团队的整体健全度。如果因为某个关键人物无法工作，就导致团队无法运作，那代表团队有单点脆弱性问题；反之，一个健全的团队，应该要做到不论谁临时无法继续工作，团队也能如期运作。

从表面来看，Code Review 是在把关品质，但除了这点外，Code Review 承担的更大责任，是传递知识，包含让团队中的新成员、资浅的成员，能从中学习如何维护团队的程序库，从团队所使用的程序风格，到如何写出健康好维护的程序，都是在 Code Review 时可以传递的。因此把 Code Review 当成一个传授指导的过程 (mentorship process)，会是资深工程师的重要责任。

除了知识面外，Code Review 有助于形塑与加强团队文化。Code Review 的过程本身就是一种沟通，在沟通时可能会有各类不同的摩擦、可能有人会有不恰当的言辞、可能有人会用消极被动的方式回应，这些不同的做法，如果在 Code Review 的过程中被默许，就会渐渐成为团队文化中的一部分。

因此，从资深工程师的角度来看，当某些可能导致文化劣化的行为出现，就需要第一时间去制止与协调，确保相关问题不会再出现，以免团队的文化变糟。

资深工程师应该要把关什么?

上一段落谈了从资深工程师的角度看，在 Code Review 的过程中，要去把关团队的文化，以下我们会谈五个推荐资深工程师要把关的面向。假如你发现你所在的团队有类似的问题，务必要主动跳出来协助改善。

假如你未来有打算面试资深工程师 (或资深以上) 的职位，在行为面试中，谈到这些守护团队文化层级的行为，也会比较能让面试官看到资深该有的讯号。

不要让低门槛的文化得逞

在许多团队中，即使有资深工程师把关，仍可能让不健康的程序被合并到主要分支中，成为程序库的技术债。往往这种状况发生在团队有些「低门槛」的审查员 (reviewer)，他们会用比较低的标准看程序，所以即使程序写得不理想，仍会让 PR 通过 (下面这个搞笑影片，在某些团队是真实存在的)。

当团队中的其他人发现这类低门槛审查员后，很可能为了让自己的 PR 快速被通过，所以每次都找那些低门槛审查员帮忙看。但这样的后果，就是参差不齐的程序被合并。这也是为什么，社群中有流传「你的程序库品质，取决于团队中最弱的审查者 Your code is only as good as your weakest reviewer」这么一句话。

因此身为团队中的资深工程师，假如看到某个 PR 明明没有到达标准却被通过，务必要在团队的会议中提出来讨论，并让团队成员了解这件事不应该发生。

更进一步，身为资深工程师可以明确地把标准订定下来。就像先前有分享过的 Google 公开分享的程序风格指南，有明确列出不同语言的程序应该要怎么写。又或者在 [在线课程] 写出好维护的程序 (上) — 经典的程序设计观点 在线课程中有谈到的原则，也可以明确放到团队的指南当中。

不要让情绪性攻击的文化得逞

前面谈到，Code Review 本身是一个沟通的过程，而沟通方式会影响团队的动态与氛围；不理想的沟通方式，甚至可能会让团队成员想要离开。

在软件业界，不乏听过有人会在 Code Review 时留下「你这是什么垃圾程序」或是「不要把这种粪程序加到我们的程序库中」这类的言论。身为资深工程师，如果看到这种可能带给团队负向氛围的留言，要第一时间跳出来制止，点出这可能带给其他成员情绪负担，是把关的重点之一。

特别注意，同样是造成人不舒服的感觉，有建设性的点评会是良药苦口，而纯粹情绪字眼的批评，则是既苦口又无效。一个运作健康的团队，应该要有办法用良好的语气来维持高标准，这两者本身不是互斥的；如果程序写得不好，可以用客观且友善的语气点出问题。

事实上，一个健康的团队应该要反过来，不仅不会让在 Code Review 中允许任何情绪字眼的攻击；当看到有人在 PR 中用不错的写法时，还会塑造鼓励与赞美的文化，例如「这样写好赞，可读性角度来说非常清楚」或者「这个测试案例写得真好，我没想过可能会出现这种极端案例」。

不要让没建设性的沟通文化得逞

当然，有些人在 Code Review 的留言，可能不会像上一段落提的例子那么极端，使用会激起对立情绪的字眼。但有另一类人，在留言时会留一些没建设性，或者对改进无具体帮助的内容。举例来说「这跟我们程序风格指南写的标准不一致」或是「这不符规范」，都是评论本身好像说了什么，但又没真的有具体指引。

如果用这种方式沟通，只会让其他人要花时间去猜为什么不符合、去推测符合标准应该怎么改写，这将导致带来的成本大于留言本身的价值。

身为替团队把关的人，要求团队成员在写留言时，要提具体有建设的论点，谈「为什么」这样写不好，以及更理想的写法应该怎么写。举例来说，假如不符合某个规范，就直接把哪一个规范写出来，然后解释为什么这样不符合。

或者可以反过来，以提问的方式，例如「今天用这种写法，假如未来要拓展到另一个使用情境，会做大幅度的改动，你怎么看这点呢?」让对方直接看出问题在哪，然后接着引导讨论更好的解决方式。

阅读更多

除了上面提到的三个点外，资深工程师还有其他应该要在 Code Review 时把关的要点，我们在 E+ 的主题文中有更详细的讨论。感兴趣的读者，欢迎加入 E+ 后阅读 (连结)。