对于很多团队来说，code review通常充满争议。即使团队知道code review很值得，但他们仍然难以使之奏效。code review通常会成为每个人的主观意见的发泄地，这会导致团队内部的争论、感情伤害和不信任。

一旦团队中开始出现不信任，就很难恢复。敌意会增长，积极性会下降，信心也会下降。代码质量也会受到影响。基于这些原因，code review流程尽量客观对你的团队的成功至关重要。

那么，如何使code review尽量客观呢？我建议你使用一个checklist。

Checklists 如何工作

创建和维护一个checklist可以让代码review不会导致团队情绪紧张。我们都知道什么是checklist。NASA将checklist提升到了另一个层次，他们为太空飞行中涉及的每一个过程定义了checklist。发射、着陆、太空行走等每个过程都有对应的checklist。

为什么要这样做？因为他们知道，在实际决策之前，通过对容易出问题的地方仔细思考，可以尽可能地消除决策的主观性。

讨论决策的目的是让所有参与的各方都能发表自己的意见，而不至于担心决策的压力。试想一下。如果你是任务控制部门的负责人，而受训多年的宇航员在发射台待命，而天气只是有点微妙，在那一刻，你有很大的压力。如果你尚未定义可接受的天气条件的阈值，那么几乎不可能做出决定。

Gene Krantz在《失败不是一种选择》（Failure Is Not an Option）一书中写到了其中的一些压力，这本书是他从头开始帮助NASA建立任务控制的回忆录。在书中，Gene讨论了他在NASA的职业生涯中所经历的失败和成功。吃一堑，长一智，从每次失败/成功中总结经验教训。他们总结这些教训的方式是调整每个过程的checklist。有了这些checklist后，他们不仅更容易做出 "去/不去 "的决定，而且他们有信心做出正确的决定。

Code Reviews 也很重要

让我们先说清楚：code review并不像将人送入太空的决定那样紧张。

然而，code review是很重要的。软件已经延伸到各个领域。医学、金融、驾驶...........航天。你所处的行业可能不需要像上面列出的一些行业那样有严格的要求，然而你写的代码会影响到人！你所写的代码会影响到世界。

作为软件工程师，我们需要尽早承担起自己作为软件工程师的责任。我们不能成为懒惰的开发人员，我们不能成为懒惰的review人员，看到代码就随便盖章。我们不能在没有测试验证修改的情况下就批准代码上线。我们不能在最后期限内忽略了代码变坏的明显迹象。

你需要一个checklist。

如何开始

你可能会想知道，我是如何开始的。"你说的很有道理，但我怎么才能弄清楚哪些是在checklist上，哪些不是？"

我的建议是这样的：你去写一份入门checklist。其中包含要你在review中的要求。在你review的过程中亲自参考你的这个checklist，并密切关注你review的代码。随着时间的推移，对它进行细化和增减。

一旦你使用了几次个人checklist，就把它向你的团队开放。不要把它强行塞给任何人，也不要强制要求使用它。只需把它作为共享资源即可。然后你的队友会帮助你完善它，并加入自己的想法/观点。即使他们会在一些事情上不同意你的观点，但如果你在其中花了心思，他们也很有可能会赞赏并使用它。

一旦每个人都开始使用它，那么就可以把它做成一个Google Doc，在每次code review时，你都会把它放在每个开发人员面前。确保它和你的团队的入职指南放在一起。要保证每个人都知道checklist的存在并能随时找到它。

例子

万事开头难。我不一定能帮你完成，但希望我可以帮助你开始。

我们的code review checklist相当短。某些应用程序中有一些针对特定问题的附加项，这些问题通常会被遗漏。我不能分享我们使用的checklist的这些细节，但它的基础部分看起来是这样的。

• 这些代码更改是否符合业务需求？

• 这些代码更改是否符合团队的编码质量要求？

• 这些代码更改是否有相关的测试？

• 这些代码更改是否有截图或用户界面更改？

• 是否为这些代码更改更新了变更日志？

• 是否为这些代码更改更新了应用文档？

这个checklist并不关注细节，比如 "我的变量是否被正确命名"，因为这些包含在第二项中。它关注代码review的核心，也就是理解。

checklist可长可短，我的建议是，越短越好，就像没有人想成为code monkey一样，也没有人想成为code review monkey（指按照checklist做机械检查）。让你的checklist专注于帮助作者和reviewer思考经常被遗忘的事情，这对你的团队会有很大的帮助。

英文原文：

https://levelup.gitconnected.com/you-need-a-code-review-checklist-1524e6a2d2cd

• 分布式算法 Paxos 的直观解释 (TL;DR)
  
• 重构，还是重写？(2020版）
• 为什么 Kubernetes 变得如此流行（2020版）
  

• Pull Request 的艺术

• Grab熔断器设计：如何应对突发打车峰值
• 手记：在 MacBook 上运行 Linux 那些坑