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

2024-01-01 18:37:28

摘要： Code Review 可以提高代码质量。

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 文化也提供了额外的好处：

Ta 可以对于 bus factor (和 key person risk 相近，意为少数关键的技术人员带队，一旦人才流失对团队是很大打击，团队抗风险能力弱)进行有效限制；
Ta 是培训新成员的一个很好的工具；
Ta 也是共享知识的好方法

在我们深入研究之前，为这篇文章中的要点做一些假设是很重要的。它们如下：

现在我们已经制定了一些基本规则，让我们深入研究。

很好理解，你即将审核的代码中，有人花了时间、付出了心血。他们会希望自己的代码写的很棒。你的同事会表现出最好的意图，没有人愿意发送蹩脚的代码。

保持客观是非常困难的。你需要始终确保批评代码本身，并尝试理解编写代码的上下文。尽可能多地取消除区隔。而不是说：

你以一种令人困惑的方式写了这个方法。

请尝试重新改写代码本身以及重新理清对 Ta 的理解：

这个方法让我有点困惑，我们能为这个变量找到一个更好的名字吗？

这里，我们会解释我们作为读者对代码的看法。这不是他们的行为或意图。这是关于我们和我们对代码的解释。

每个 PR 都是它自己的艰难对话。尝试与您的同事达成共识，共同努力实现更好的代码。

如果您刚刚结识了同事，并且您对 PR 有重要反馈，请一起浏览代码。这将是一个与同事建立关系的好机会。与每位同事一起做到这一点，直到这件事情让你不再感觉尴尬。

如果计算机可以决定并执行规则，请让计算机执行此操作。无休止地争论 Space 与 Tab 并不能充分利用时间、提高任何效率。相反，应该花时间对于规则达成一致意见。在低风险情景中，这有机会可以让你了解你的团队在 “不认同但承诺”方面的表现。

语言和现代工具链不缺乏执行规则（linting）和复用它们的方法。在 Ruby 中，你有 Rubocop; 在 JavaScript 中，Jslint/eslint。找到你的语言的 linter 并将其插入你项目的构建流程。

如果您发现缺少现有的 linter，请自己编写！编写自己的规则非常简单。在 Gusto 中，我们使用自定义的 linter 规则来捕捉类的弃用或温和地提醒人们遵守一些 Sidekiq 的最佳实践。

将所有代码审查职责一股脑全交给 Shirley 是很诱人的。

Shirley 是一个关于代码的大师，她总是知道什么是最好的。她知道系统的来龙去脉，而且她在公司工作的时间超过了团队的集体任期。

然而，仅仅因为 Shirley 理解某些事情并不意味着她的团队中的其他人可以理解。年轻的团队成员可能会对指出 Shirley 的代码评论的问题而犹豫不决。

我发现将评论分发给团队的不同成员会产生更健康的团队互动和更好的代码。初级工程师在代码审查中最强大的一句是“我发现这令人困惑。”这些就是使代码更清晰，更简单的机会。

请传播这些评论。

在 Gusto，我们使用 GitHub 来管理我们的代码项目。几乎 GitHub 上的每个<textarea>都支持Markdown，这是一种在评论中添加 HTML 格式的简单方法。

拥抱 Markdown 是让事物变得可读的好方法。GitHub 或您选择的工具可能具有语法突出显示，这对于删除一些代码片段非常有用。使用内联代码的单反引号（`）或代码块的三重反引号（```）可以更好地传达想法。

熟悉 Markdown 语法，特别是在注释中编写代码时。这样做有助于保持您的评论具体和专注。

代码评论本质上是负面的事情。在我要将此代码发布到线上环境之前告诉我这个代码有什么问题，这是挺伤人的事儿。有人花时间在这上面，并期望你会指出它会如何变得更好。

因此，请至少留下一个积极的评论。让它变得有意义和极具个性。如果有人终于掌握了他们一直在努力的掌握的事情，那么就请你把它 Ta 出来。它可以像点个赞

码农公寓