不要忽视代码审查的重要性

这是一篇译文，以为它很不错就把它翻译了一下。原文名为 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个技巧能帮助你和你的团队有更好的代码审查。经过改进代码审查过程，你将拥有更好的代码、更快乐的团队成员，带来更好的业务。