8 个 Tips 让你更好的进行 Code Review

摘要： Code Review 能够提升代码质量。

• 原文：Elevenbeans
• 做者：前端小智

Fundebug经受权转载，版权归原做者全部。

原文地址：https://kellysutton.com/2018/10/08/8-tips-for-great-code-reviews.html
更多内容请见译者 Blog：https://github.com/elevenbeans/elevenbeans.github.io

你在学校里未曾学到的东西中有一件是：如何才作出优秀的 Code Review。你学到了算法、数据结构、编程语言基础知识，但没有人坐下来讲：“下面介绍如何确保你如何（对同事）提出很棒的反馈（Code Review）”。

Code Reviews 是开发出好软件的关键过程。通过审核的代码每每质量较高、错误较少。一个良性的 Code Reviews 文化也提供了额外的好处：

1. Ta 能够对于 bus factor (和 key person risk 相近，意为少数关键的技术人员带队，一旦人才流失对团队是很大打击，团队抗风险能力弱)进行有效限制；
2. Ta 是培训新成员的一个很好的工具；
3. 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 出来。 它能够像点个赞 👍 或 “喜欢这个” 同样简单。

在每次 Code Review 中留下一些正面的内容都是微妙的提示：咱们是在一块儿合做。若是咱们生产出更好的代码，咱们都会受益。

6. 提供替代方案

一些我尝试作的事情是（尤为是在和那些只是学习语言或框架的人合做的时候）：提供替代方案。

当心这个。若是表达不正确，它可能会变得傲慢或自私：“这就是我作的方式”。请尽可能保持客观，并讨论你提供的替代方案的利弊权衡。作得好，这应该有助于扩展每一个人对手头技术的了解。

7. 响应时间是关键

Code Review 过程快速流转很是重要。（使用如下规则能够更容易：保持细粒度）

长段时间 Code Review 延迟可能会下降生产力和士气。听到你在 3 天前就已经分提交给审查的 PR 的 feedback 是使人不快的。哦耶。我在这作什么？来回切换开发环境和代码上下文。要纠正这个问题，您须要提醒您的团队，衡量进度须要从团队的视角出发而非我的。让您的团队关注代码审查延迟，并在团队中变得更好。

若是您但愿减小本身的审核延迟，我建议遵循如下规则：在编写任何新代码之首先 Review 代码。

做为解决延迟的策略，请尝试结对作 Code Review。搞一个配对站或启动一个屏幕共享来讨论 Code Review。一块儿寻求解决方案并将代码置于批准状态。

8. 保持细粒度

你在 Code Review 上收到的反馈质量将与 Pull Request 的大小成反比。

为了保持反馈的尖锐和建设性，最好知道较小的 Pull 请求使读者更容易。

若是你保持 PR 很小（并避免Teeth），你须要有一个不一样的场所来进行更大纬度的对话。 这个单一的 Pull Request 如何适应本周或本月的工做？咱们要去哪里，这个 Pull Request 如何让咱们在那里？白板和临时对话很是适合这些类型的讨论。对于较小的 Pull 请求，可能很难记住它所写的上下文。

“小”将因语言和团队而异。 对于我本身，我试图让 Pull Requests 总共少于 300 行。

结语

但愿这 8 个技巧能够帮助您和您的团队更好的进行 Code Review。经过改进您的 Code Review 流程，你将得到更好的代码质量，更快乐的团队成员，并有但愿创造出更好的业务。

关于Fundebug

Fundebug专一于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java线上应用实时BUG监控。 自从2016年双十一正式上线，Fundebug累计处理了10亿+错误事件，付费客户有Google、360、金山软件、百姓网等众多品牌企业。欢迎你们免费试用！