这是一篇译文，觉得它很不错就把它翻译了一下。原文名为 8 Tips for Great Code Reviews，这篇文章不管是对提升个人编程素养，还是协调团队间的合作都有一定的指导意义。
在学校里没有教给你的一项本领就是怎样做一个好的代码审查(CR)。你学习了算法、数据结构、编程语言的基础知识，但没有人会坐下来对你说:“下面是如何确保你能获得很好的反馈的方法。”
代码审查是创建优秀应用的关键过程。经过审查的代码往往质量更高，bug 更少。健康的代码审查文化也提供了额外的好处：限制了巴士因子，它是培训新成员的一个很好的工具，代码审查是分享知识的好方法。
在我们深入讨论之前，有必要对这篇文章中的观点限制一下适用环境。限制条件是：
你在一个信任的环境中工作，或者你和你的团队正在努力提高你的信任。
你应该能够在非代码场景中交付反馈，或者在团队中交付反馈。
你的团队希望生成更好的代码，并且理解完美是一个动词而不是形容词。我们明天可能会找到更好的做事方法，我们需要保持开放的心态。
你的公司重视高质量的代码，并且理解事情可能不会“交付”得那么快。“交付”是用引号括起来的，因为很多时候没有经过测试和审查的代码可能根本无法工作。
既然我们已经指定了一些基本限制条件，那么让我们开始吧。
1. 我们终究还是人
要知道有人会在你要检查的代码上花时间。他们希望它是伟大的。你的同事的行为是出于好意的，没有人想要发布糟糕的代码。
保持客观很难。确保始终对代码本身进行评论，并尝试在上下文中理解所编写的代码。尽你所能的把偏见去掉，不要这样说：“你用一种使人困惑的方式写了这个方法。”，试着换一种说法，把事情说成是关于代码本身和你对它的解释：“这个方法让我有点困惑。这个变量有没有更好的名字?”
在这个例子中，我们解释我们作为读者对代码的感受，这与自身的行为或意图无关。它是关于我们和我们对代码的解释。
每一个拉请求（Pull Request）都是一个艰难的对话。试着与你的队友达成共同的理解，并一起朝着更好的代码努力。
如果你只是了解一个团队成员，并且你对拉请求（Pull Request）有关键的反馈，那么一起浏览代码。这将是开始与同事建立关系的好机会。和每位同事这样做，直到他们不再感到尴尬。
2. 自动化
如果电脑能决定并执行一条规则，就让电脑去做吧。在空格和制表符之间争论并不是对人类时间的有效利用, 相反把时间花在就规则应该是什么达成一致上。这些机会可以让你看到你的团队，在低风险的情况下如何处理“不同意和承诺”。
现代的编译语言工具和语言可以开启语法检测功能，并反复使用它们。在 Ruby 中，有 Rubocop；在 JavaScript 中，有 eslint；在 CSS 中，有 stylelint。找到你需要的语法检测工具，并将其插入到构建工具中。
如果你发现现有的语法检测工具动力不足，可以尝试写你自己的！
3. 每个人都是代码审查者
将所有代码审查责任都交给 Shirley，咋一听来是很有诱惑力的。
虽然，在编写代码方面，Shirley 是一个奇才，她总是知道什么是最好的，她了解公司制度的来龙去脉，而且她在公司工作的时间比你们团队的集体任期还要长；
然而，Shirley 理解了这些事情，并不意味着她的团队中的其他人也都理解。年轻的团队成员可能会犹豫是否要在 Shirley 的代码评审中指出一些问题。
我发现将评审分发给团队的不同成员会产生更健康的团队动态和更好的代码。一个初级工程师在代码评审中最有力的一句话是：“我觉得这很混乱”。这些都是使代码更清晰、更简单的机会。
推广这些评论。
4. 增强可读性
我们使用 GitHub 来管理我们的代码项目。几乎每个 GitHub 上都支持 Markdown，这是一种向评论添加 html 格式的简单方法。
拥抱 Markdown 是让代码变得更加可读。GitHub 或你选择的开发工具可能有语法高亮显示功能，这对于插入一些代码片段非常有用。对于内联代码使用单回勾 () 或者对于代码块使用（“）可以更好地交流思想。
熟悉标记语法，特别是在注释中编写代码时。这样做将有助于使你的评论更加具体和集中。
5. 至少留下一句积极的评论
代码审查本质上是负面的。在把代码发送之前，告诉代码的作者这个代码有什么问题，这是基本。但有些人在这这个代码上面花了时间，他们希望你能指出怎样才能做得更好。
因此，至少留下一句正面的话。让它有意义和个性化。如果了解到他们一直在努力的解决问题，那就大声喊出来，这可以简单 ???? 或“Love this.”
在每个代码评审上留下一些积极的内容，可以微妙地提醒我们，我们是在一起的。如果我们创建更好的代码，我们都会受益。
6. 提供替代方案
我常常尝试着去提供一个可替代的实现方案。对那些只学习了一门语言或框架的人更应该如此。
当要注意表达的方式。如果表述不正确，可能会让人觉得你傲慢或自私。“尽量保持客观，并讨论你所提供的备选方案的利弊。”如果做得好，这将有助于扩展每个人的技术知识。
7. 审查延迟
保持一个极快的代码审查速度非常重要的。(实现这个规则很简单：保持审查代码足够小。)
长时间的代码审查延迟会扼杀生产力和士气。如：“3 天前，你被分配去审查一份 xxx 的任务”，这听起来很刺耳。
如果你希望减少自己的审查延迟，我建议遵循以下规则：在编写任何新代码之前审查代码。
作为一种直接处理延迟的策略，尝试在代码评审上进行配对。启动一个屏幕共享来浏览和讨论评论。对解决方案进行配对，使代码达到批准的状态。
8. 对于发件人来说：保持内容尽量小
你在代码评审中收到的反馈质量将与拉请求 (Pull Request) 的大小成反比。
为了最大限度地保持反馈的尖锐和建设性，要知道较小的请求会让读者更容易接受。
如果你的拉请求（Pull Requests）很小，怎么办？这时你需要有一个不同的地方来进行详细的描述。如：这个单一的拉请求（Pull Request）如何适合本周或本月的工作？我们要去哪里，这个拉请求是如何让我们到达那里的？这种对话类型的方式在表现效果方面是很好的，因为对于较小的 Pull 请求，你很难记住它的编写上下文。
小 这个概念会因语言的不同和团队的不同而不同。对于我自己来说，我试图让 Pull 请求总数少于 300 行。
结论
希望这 8 个技巧能帮助你和你的团队有更好的代码审查。通过改进代码审查过程，你将拥有更好的代码、更快乐的团队成员，带来更好的业务。