代码评审

这不是一个全面的代码评审指南，但提供了一些粗略的指导原则，旨在统一本项目中的通用评审实践。

首先，让评审花费一些时间。如果可能，尝试阅读添加的每一行代码。也尝试运行一些测试。如果需要理解引入的更改，请阅读代码的周围上下文。如果有什么不理解的地方，可以寻求澄清。如果拉取请求的更改难以理解，这可能表明代码还不够清晰。但是，不要对每个细节都吹毛求疵。

其次，先关注主要事项，然后再处理较小的事项。重要级别

• 立即阻止合并的问题（代码功能错误，或者不应该添加该功能等）

• 合并前需要修复的事项（添加更多文档，降低复杂度等）

• 更主观的事项可以在作者同意的情况下进行更改。

第三，只有当您认为更改“提高了整体代码健康度”（如此处所述）时，才批准拉取请求。但这并不意味着拉取请求必须完美无缺。有些功能最好通过多次拉取请求逐步实现，您应该更关注确保引入的更改能够为后续的改进提供便利。

第四，利用 GitHub 提供的工具：在特定代码行上评论，建议编辑，并且在所有相关人员都同意 PR 已准备好合并后，合并请求并删除 feature 分支。

第五，代码评审是进行专业建设性批评的场所，一个很好的策略来展示（并验证）您真正理解了 PR 在做什么，是通过对其优点提供一些肯定性评论。