代码评审的 8 点建议
学校有一点没有教你的是：如何进行代码评审。你学习了算法、数据结构，以及编程语言基础，但没有人坐下来说：“这是一些能让你提出更好的反馈的办法”。
代码评审是编写良好软件过程中的关键步骤。代码评审在于尽可能使得其具备高质量且 bug 少的特点。良好的代码评审文化也会带来其他收益：你减少了产生 bug 的因素；同时代码评审也是培养新成员和分享知识的良好途径。
假设
阅读本文之前，有必要作出几点假设，如下：
- 你在一个受信任的环境中工作，或者你和你的团队正在改善你的信任度。
- 你可以在非代码环境中提出反馈，也可以在你的团队中提出反馈。
- 你的团队希望产出更好的代码，也理解 perfect 是一个动词而非形容词。我们可能会为明天的工作找到更好的解决方案，同时我们需要保持开放的心态。
- 你的公司注重代码的质量，并且理解高质量代码或许无法快速“上线”。这里引用“上线”是为了说明：很多时候未经测试和评审的代码实际上可能不起作用。
有了上述假设条件，接下来让我们进入正文。
1. 我们是人类
要知道其他人在你将要评审的代码中投入了很多时间，他们也想让代码质量更高。你的同事（通过代码）努力地表达自己的意图，谁也不想写出蹩脚的代码。
保持客观是很困难的。请确保总是评判代码本身，并试着去理解上下文的含义。尽可能减轻评判带来的不良影响。不要说：
你写的这个方法令人费解。
尝试换个说法以针对代码本身，并增加你的解释：
这个方法有点不好理解，我们是否可以为这个变量起一个更好的名字呢？
这个例子中解释了我们作为读者时对代码的感觉，这关乎于我们自己以及我们对代码的解释，而与编写者的编码方式或意图无关。
每个的 Pull Request 都有它本身的高难度交流。尝试与你的队友达成共识, 共同努力以实现更好的代码。
如果你刚刚认识一名团队成员，并且针对某个 Pull Request 有一些重要反馈，请共同浏览一遍代码。这将是发展同事关系的一个好机会。以这种方式与每个同事合作，直到你不再感到难为情。
2. 自动检查
如果计算机可以决定并执行一条规则的话，那就让计算机完成它。争论应使用空格还是 tabs 属于浪费时间。相反，应把时间花在制定规则上并且达成一致。这也是观察团队如何在低风险情景下处理“反对还是提交代码”的机会。
编程语言和现代工具流不缺乏执行规则（的辅助检查程序）并反复应用它们的方法。在 Ruby 中，有 Rubocop；在JavaScript中，有 eslint。找到语言这类辅助检查程序，并将其嵌入到构建流中。
如果你发现现有的辅助检查程序存在不足，那么可以自己编写！定制规则相当简单。在 Gusto 中，我们使用定制的辅助检查规则来捕获类的废弃用法，或者适当地提醒人们遵守某些 Sidekiq 最佳实践。
3. 全员评审
听起来，把全部的代码评审工作交给 Shirley 是一个好主意。
Shieley 是一位大牛，她总是知道如何有效编程。她清楚系统的输入输出，在公司呆的时间比团队成员的总和都要长。
然而对于某些事情，Shirley 理解它并不代表其他团队成员也理解了。评审 Shirley 的代码时，年轻的团队成员或许会在指出某些问题时犹豫不决。
我意识到将评审工作分配给不同的成员会产生有益的的团队动力和更好的代码。一名初级工程师在某次代码评审中作出的最有力的评论是：“我看不太懂。”这是使代码变得更加清晰简单的机会。
在团队中推广代码评审。
4. 保持可读性
在 Gusto 中，我们使用 GitHub 管理我们的项目。GitHub 中的每个