有效的代码审查

代码审查介绍

审查代码不是一件容易的事。大多数时候代码审查都以拉取请求的形式出现（从现在开始是 PR）。在解决这些问题时，我们都有自己的风格和指导方针，因此在这篇文章中，我将分享我自己的技巧，以使它们有效且有价值。

作为起点，我想提出一些鼓舞人心的编码引语，我在编写代码时牢记这些：

“始终编码，好像最终维护您代码的人将是一个知道您住在哪里的暴力精神病患者。” - 约翰·F·伍兹

“程序必须是为人们阅读而编写的，而只是偶然地为机器执行而编写。” - 哈罗德·阿贝尔森

“我不是一个伟大的程序员；我只是一个有很好习惯的优秀程序员。” - 肯特贝克

它适用于我的机器......让我们从探索一系列领域开始，这将有助于我们在代码审查中创建结构和组织，以及在流程中需要注意的事项。

目的和重要性 

在开始审查代码的过程之前，我们需要了解代码审查背后的原因以及它们如何促进更好的软件开发。

让我们一一列举：

• 他们确保代码质量：四只眼睛看到两个以上。

• 它们充当文档：它们可用于理解、学习并及时返回以检查技术决策。

• 他们鼓励协作和贡献：团队合作才能获胜。

• 他们培养工程文化：这是一个提出问题、分享专业知识以及提出更改和修复建议的绝佳机会。

有效的代码审查可确保代码质量。

公关尺寸 

代码审查的第一个也是最重要的部分是它的 PR 大小。提供简洁的大小以方便审查是关键：保持简短和直截了当。

根据经验和我的经验：

• 200 行代码很棒。

• 400 行代码很好并且易于管理。

• 超过500 行代码是事情开始变得势不可挡的地方。

请记住，有效的代码审查很小而且经常发生，如果您觉得自己违反了这条规则，请尝试将代码分解成更小的块。

在重命名或重构等涉及更大变更集的情况下（由于耦合、遗留代码或技术债务：我们已经在那里了，对吗？），您可以在 PR 描述中指定，甚至可以*与某人配对并直接提交更改。

PR说明 

一个好的 PR 描述是快速获取需要审查的上下文的关键。描述和公关本身应该遵循单一职责原则：做一件事并做好。

它们基本上应该包含（尽可能短）：

• 工单：链接到您正在使用的问题跟踪器中的工单。

• 目的：什么？

• 理由：为什么？

• 实施细节：如何？

• 测试：测试用例的快速解释。

• 文档：如果需要，链接到文档。

童子军规则：我知道在 PR 范围之外重构某些东西并将其包含在其中是很诱人的，但是......尽量不要落入这个陷阱，并对审查代码的人保持温和。在这个意义上严格是很重要的：你总是可以用这个变更集创建另一个小的 PR。

专业提示：如果您使用的是Github，您可以创建模板（以保持一致性）以包含在 PR 描述中的所需字段。每次创建 PR 时都会触发此模板。. 这是一个例子

态度与沟通 

PR 中的通信本质上是异步的，因此我们需要小心不要阻止人们。审查代码是一种责任，它不是“一触即发”的过程，所以让我们确保我们监控我们的对话和/或请求的更改。

在态度方面，我的建议是：

• 始终提供建设性的反馈：积极的评论。

• 保持客观：尽量去除个人品味，并始终有技术理由来支持您的技术论点。

• 不要个人评论。

• 冒充评论和讨论： “你能重命名这个常量吗？” 应该是“这个常量需要重命名”。

我们应该始终保持积极的态度并提供建设性的反馈。

代码质量 

在文章的开头我们强调了代码质量是代码审查的最大好处之一，这就引出了一个问题：在这个层面上我们需要注意什么？

测试 

我在审查代码时做的第一件事是向下滚动到 PR 的底部以查看测试的存在：

• 如果我没有找到，那么我会自动请求更改。

• 如果我确实找到了它们，那么我会确保：

  • 我理解它们，这有助于更好地理解 PR 的范围和目的（测试本质上充当文档）。

  • 它们设计得很好。

PRO提示：目前存在的工具来测量代码覆盖整体在你的代码或每PR，像codecov：

在 PR 中包含代码覆盖率非常重要。

设计 

要在代码层面检测问题，尽管精通我们正在评估的技术很关键，但熟悉代码反模式、代码异味、软件工程设计原则和最佳实践更为重要，因此，我们拥有这些知识将为我们提供额外的工具来轻松检测潜在问题。

在这方面，我检查：

• 代码味道：神类/函数、幻数、命名约定、代码意图等。

• 代码经过精心设计并与代码库的其余部分保持一致。

• 有没有不必要的复杂性。

• 该功能便于其他开发人员使用/阅读/理解。

• 如果涉及 UI，更改看起来不错。

• 并行编程、 安全性和属于 PR 范围的任何其他方面。

• 代码样式：缩进、空格/制表符/行或符合我们所拥有的样式指南的任何其他方面。

• 代码文档：例如 api 或开源项目。

有效的代码审查有助于提高代码质量。

工装 

• 您的 IDE：最好的方法是实际拉取您的 PR 分支并在本地运行它。

• 您的 Git 存储库托管服务：例如Github或Gitlab，它们提供友好的 Web 工具来比较代码、评论、突出显示、跟踪更改、提交等。

• 如果您管理自己的 Git 服务，那么Gerrit是由 Google 开发的众所周知的开源替代品。

• 几个付费工具：Crucible或Upsource。

结论 

错误的代码审查可能会成为大祸害，导致关键问题，不仅在技术层面，而且在协作和团队士气方面。 如果我们在审查代码时创建一致性、结构和组织，我们将为更好的流程、讨论和更高的软件质量做出贡献。

进行有效的代码审查可以获得很多好处，我希望这篇文章对这个主题有所了解。像往常一样，非常欢迎任何反馈或提示！ 快乐编码！