摘要： Code Review 可以提高代码质量。
- 原文：Elevenbeans
- 作者：前端小智
Fundebug经授权转载，版权归原作者所有。
你在学校里不曾学到的东西中有一件是：如何才做出优秀的 Code Review。你学到了算法、数据结构、编程语言基础知识，但没有人坐下来说：“下面介绍如何确保你如何（对同事）提出很棒的反馈（Code Review）”。
Code Reviews 是开发出好软件的关键过程。经过审核的代码往往质量较高、错误较少。一个良性的 Code Reviews 文化也提供了额外的好处：
- Ta 可以对于 bus factor (和 key person risk 相近，意为少数关键的技术人员带队，一旦人才流失对团队是很大打击，团队抗风险能力弱)进行有效限制；
- Ta 是培训新成员的一个很好的工具；
- Ta 也是共享知识的好方法
假设
在我们深入研究之前，为这篇文章中的要点做一些假设是很重要的。 它们如下：
- 你在信任的环境中工作，或者您和您的团队正在努力提高你对他们的信任度；
- 您应该能够在非代码方案中提供反馈，或者正在努力在您的团队中提供反馈；
- 你的团队希望产生更好的代码，并且理解完美是动词而不是形容词。 我们明天可能会找到一种更好的做事方式，我们需要保持开放的心态；
- 你的公司重视高质量的代码，并理解业务可能不会快速“交付”。用引号是因为未经测试和未经审核的代码实际上可能无法正常工作；
现在我们已经制定了一些基本规则，让我们深入研究。
1. 我们是人类
很好理解，你即将审核的代码中，有人花了时间、付出了心血。他们会希望自己的代码写的很棒。你的同事会表现出最好的意图，没有人愿意发送蹩脚的代码。
保持客观是非常困难的。你需要始终确保批评代码本身，并尝试理解编写代码的上下文。尽可能多地取消除区隔。而不是说：
请尝试重新改写代码本身以及重新理清对 Ta 的理解：
这里，我们会解释我们作为读者对代码的看法。这不是他们的行为或意图。这是关于我们和我们对代码的解释。
每个 PR 都是它自己的艰难对话。尝试与您的同事达成共识，共同努力实现更好的代码。
如果您刚刚结识了同事，并且您对 PR 有重要反馈，请一起浏览代码。这将是一个与同事建立关系的好机会。与每位同事一起做到这一点，直到这件事情让你不再感觉尴尬。
2. 自动化
如果计算机可以决定并执行规则，请让计算机执行此操作。无休止地争论 Space 与 Tab 并不能充分利用时间、提高任何效率。相反，应该花时间对于规则达成一致意见。在低风险情景中，这有机会可以让你了解你的团队在 “不认同但承诺”方面的表现。
语言和现代工具链不缺乏执行规则（linting）和复用它们的方法。 在 Ruby 中，你有 Rubocop; 在 JavaScript 中，Jslint/eslint。 找到你的语言的 linter 并将其插入你项目的构建流程。
如果您发现缺少现有的 linter，请自己编写！ 编写自己的规则非常简单。 在 Gusto 中，我们使用自定义的 linter 规则来捕捉类的弃用或温和地提醒人们遵守一些 Sidekiq 的最佳实践。
3. 全员参与
将所有代码审查职责一股脑全交给 Shirley 是很诱人的。
Shirley 是一个关于代码的大师，她总是知道什么是最好的。她知道系统的来龙去脉，而且她在公司工作的时间超过了团队的集体任期。
然而，仅仅因为 Shirley 理解某些事情并不意味着她的团队中的其他人可以理解。年轻的团队成员可能会对指出 Shirley 的代码评论的问题而犹豫不决。
我发现将评论分发给团队的不同成员会产生更健康的团队互动和更好的代码。初级工程师在代码审查中最强大的一句是“我发现这令人困惑。”这些就是使代码更清晰，更简单的机会。
请传播这些评论。
4. 增加可读性
在 Gusto，我们使用 GitHub 来管理我们的代码项目。几乎 GitHub 上的每个<textarea>都支持Markdown，这是一种在评论中添加 HTML 格式的简单方法。
拥抱 Markdown 是让事物变得可读的好方法。GitHub 或您选择的工具可能具有语法突出显示，这对于删除一些代码片段非常有用。使用内联代码的单反引号（`）或代码块的三重反引号（```）可以更好地传达想法。
熟悉 Markdown 语法，特别是在注释中编写代码时。 这样做有助于保持您的评论具体和专注。
5. 至少留下一个积极评论
代码评论本质上是负面的事情。在我要将此代码发布到线上环境之前告诉我这个代码有什么问题，这是挺伤人的事儿。有人花时间在这上面，并期望你会指出它会如何变得更好。
因此，请至少留下一个积极的评论。让它变得有意义和极具个性。如果有人终于掌握了他们一直在努力的掌握的事情，那么就请你把它 Ta 出来。 它可以像点个赞