当需要在现有项目中添加新代码时，应在主代码库（通常是 master/main/test 分支）的基础上创建功能分支。这样，个人或团队就可以对新功能或任务进行开发，直到完成为止，并将他们的提交推送到这个不受保护的分支。

开发完成后，就需要打开一个拉取请求（PR），将这些更改合并到主代码库中。这是为什么呢？因为代码审查必须由作者以外的人员执行，以检查源代码并查找问题，确保不良代码不会进入生产。此外，知识共享、提高安全性、降低开发成本和促进团队合作也是代码审查的好处。

下面概述了进行有意义、有效的代码审查的一些技巧和最佳实践，以及防止将拉取请求合并到主代码库的规则。

最佳实践与技巧

在进行代码审查时，可能需要考虑以下几个方面：代码的设计、风格、功能、复杂性、命名、测试...... 以下主题应能为执行代码审查提供一些指导：

验证功能需求--问问自己 "这段代码能满足最终用户的需求吗？验证 PR 和 Jira 问题描述中提供的信息以及定义的验收标准。是否存在功能缺失？是否有执行不力的功能？

评估可读性--代码不仅要满足最终用户的需求，还要易于理解。您能否轻松识别代码块的开始和结束位置？代码是否言之有物并表达了其目的？是否避免了晦涩难懂的语言？你能分辨出特定函数、方法或类的作用吗？开发人员是否将代码分成了易于理解的小块？

测试可维护性--正如代码需要易于理解一样，它也需要易于维护。代码是否易于测试和调试？能否配置代码以快速更改数据值？代码是否与其他系统或过时的程序绑定？代码是否依赖于您希望淘汰的功能或技术？

检查安全漏洞--虽然 SonarQube 可以在这方面提供帮助，但仍需要人工检查安全漏洞。代码是否使用过时的工具或存在已知安全问题的工具？如果你想窃取数据或访问系统，你能看到漏洞吗？代码是否利用身份验证和授权来保证安全？是否对用户输入进行了消毒以防止安全攻击？代码是否安全地存储用户数据？

考虑速度和性能--用户希望该功能能按照他们的需求运行，不存在安全问题，而且速度和性能可靠。因此，您需要提出这些问题： 代码中是否包含低效的字符串连接、日志记录或对象分配？是否存在不需要的重复代码？程序是否会对系统整体性能产生负面影响？代码是否依赖于优化不佳的资产或多个 API 请求？

确认有足够的文档--虽然代码本身应该能说明问题，但为了便于使用，可能还需要一些外部文档。那么，文档是否解释了代码的目的，并教会用户如何使用代码？任何新功能或代码变更是否需要额外的文档？文档是否清晰易懂？

检查命名约定--这是评估可读性的一个子话题，但拥有清晰的命名约定会让代码更容易阅读和理解。您可以通过查看变量、常量、类字段、属性和方法的名称来检查命名约定。这些名称是否简单易读？这些名称是否符合您企业的命名约定，或表达了函数或变量的含义？名称是否解释了整个代码库的上下文或范围？

合并拉取请求的规则

为了保护master/main/test 分支不会收到未经适当审核的代码，并最大限度地降低生产事故的风险，启用了以下规则：

要求 PR 中至少有两个批准，其中至少一个应属于代码所有者。打开 PR 的人不能是批准人之一。

在推送新提交时取消状态拉取请求审批，并要求审批最近一次可审查的推送。这样，我们就能保证在批准后没有任何更改，从而最大限度地减少将问题推送到生产环境的可能性。

要求在合并前通过状态检查，并要求在合并前更新分支。这能确保 PR 已使用最新代码进行了测试，并符合持续集成管道中定义的最低要求。

要求在合并前解决对话问题，确保不会忽略或忽视任何评论。

要求提交签名，以确保提交的真实性和完整性，证明提交是由推送到特性分支的人完成的。