代码审查指南

代码审查是科技行业的常见做法。当你提交拉取请求/合并请求时，需要有人对其进行审查、提供反馈，并在其准备好成为主分支的一部分时批准它——当然，前提是主分支是该 PR 所指向的分支。


如果你是第一次担任审查员，或许你已经从收到的评论中学到了一些。别害怕，这没什么大不了的。代码审查也是为了学习。你不是在攻击你的队友，这不是针对你个人的事情。你是在质疑他们的代码，并研究如何改进它。

请记住，代码审查不仅仅是为了查看哪里出了问题，也是为了向他人学习。

带着这种心态，让我们看看如何做到这一点：

有背景

每个 PR 都有其用途。它可能是提案的一部分、错误修复、新功能等等。在查看代码之前，请务必阅读并理解 PR 的标题。
这能让你更好地了解要审核的内容。查看修改了哪些文件，可以更好地了解其范围。
确保修改的文件符合 PR 的预期（也许他们突然错误地上传了文件）。

好的，我们已经知道这个 PR 应该做什么了。让我们看看代码。你可以从两种角度来审查它：可读性和功能性。
无论你选择哪种方法，请始终牢记以下两个问题：

• 我怎样才能改善这种情况？
• 可能出现什么问题？

按可读性进行审核

这也许是你开始审查代码最肤浅的方式，但它能确保代码随着时间的推移更容易维护。如果你现在看不懂那段代码，一年后你也看不懂。

你写的每一段代码都有代价：维护。帮别人一个忙，仔细检查一下。

以下是您可以查看的一些内容：

• 查找拼写错误 - 它们总是会发生 - 在变量和函数名称中，在注释描述中，甚至在文件名中。
• 类和函数的命名都很恰当。函数的职责与名称相符。
• 描述性强且文笔流畅的评论。但这并不意味着评论应该很长，要表达清晰。
• 一致性。代码在代码库中并非孤立存在。确保其符合实践。尽量确保你正在审查的代码与其他代码保持一致。

例如，这种情况发生在案例样式中：

// camelCase
// PascalCase
// snake_case
// kebab-case

确保所有代码都和谐一致，并且他们要添加的部分不会产生噪音。

• 没有打印语句。也许他们在调试时忘记了。
• 避免不必要的嵌套语句。
• 尽可能早地返回如果你看到如下代码：

var myVar = "I am a variable"

if strings.ContainsAny("a", myVar){
   return myVar
}else{
   return nil
}

您可以按照如下方式重构它：

var myVar = "I am a variable"

if strings.ContainsAny("a", myVar){
   return myVar
}

return nil

提出任何您认为必要的建议，以使代码更好地被理解。

按功能审核

作为审核员，您还要对公司交付生产的代码质量负责。请注意细节、可扩展性，尤其是安全性。

• 流程合理吗？
• 是否存在不必要的验证、循环等等？
• 方法和类的职责单一。因此测试可以更加原子化。
• 它容易失败吗？例如，确保在访问数组之前检查其长度。或者至少确保它不会引发错误——NullPointer 警报——
• 我会怎么做？我的方法更好吗？之前的逻辑能改善现在的逻辑吗？
• 测试不会无缘无故地更改。例如，如果测试原本用于验证函数是否抛出错误，但后来又用于验证函数是否抛出错误，请问原因。这可能会导致影响操作的重大更改。
• 不要无缘无故地删除测试。如果你不明白为什么测试被删除，就问问为什么。这不再有必要了吗？为什么？
• 这些测试足以满足变更的影响。此外，还要检查测试是否正确断言了它们应该说的内容。

不懂代码语言怎么办？

这是一个经典的例子。你不了解某种编程语言或技术，但必须对其进行评审。
首先，不要害怕。确保其他评审员了解该语言，因为他们能发现你无法发现的东西。如果有必要，可以询问他们。
一个好的起点是进行粗略的评审：查找拼写错误和变量的命名错误。
如果你愿意，可以搜索同一语言的代码库中的其他代码，并尝试发现其中的规律。记住，如果有任何不清楚的地方，你可以提问。

最重要的建议是：不要盲目遵循“最佳实践”。务必三思而后行。每一段代码都在努力为产品增添价值。思考一下它如何能够为以后维护该代码的开发人员（或许就是你）带来价值，并使其工作更轻松。

本文最初发表于Medium
，感谢阅读：）