改进 GitHub 代码评审的 5 个技巧

代码审查是程序员最简单但同时也是最强大的机制之一。不幸的是，它也常常被低估。在我之前的工作中，我和队友们经历了从零开始到建立起一个组织有序、运行良好的流程的历程。这值得我们投入时间和精力吗？当然值得！以下是一些基于我们经验的想法和技巧。

让我们从头开始——什么是代码审查？

如果你是一名程序员，你可能听说过这个说法。但对于技术新手，我们先来了解一下它的简短定义。代码审查（简称 CR）是指由二级工程师在将代码合并到主代码库之前审核你的变更的一种做法。这种极其简单的操作可以提高代码质量，并加速团队间的知识共享。此外，它还有助于避免错误（尤其是像架构问题这样复杂的错误）。所有最流行的版本控制平台，例如 GitHub 或 GitLab，都准备了专门的工具来在其环境中支持 CR。大多数公司和团队都有专门的标准，定义 CR 应该是什么样子，以及在将代码合并到主分支之前需要多少个审批。以下是我认为在制定标准时非常有用的 5 个技巧。

1. 受保护的分支

首先，保护你的主分支免受意外更改的影响。无论是有人git push在错误的分支上本地调用，还是其他团队中不了解你标准的人员试图向你的代码库添加内容，都没有关系。直接将代码推送到主分支应该是不可能的。幸运的是，GitHub 提供了一种名为“受保护的分支”的出色机制。你可以为一个或一组分支创建特殊规则（例如，基于名称模式），定义例如拉取请求和至少一位审阅者的批准才能将代码合并到主分支。

如何配置？

1. 前往 github.com 并导航到你的存储库
2. 单击“设置”选项卡
3. 在左侧菜单中单击“分支”选项
4. 点击添加分支保护规则按钮
5. 在分支名称模式输入中输入分支名称或名称模式的正则表达式
6. 从下面的清单中选择一个可用的项目
7. 保存更改

2. 标签

对我来说，这是一个非常小巧但极其实用的功能，尤其是在大型开源代码库中。标签只不过是拉取请求列表中一些额外的、易于查看和过滤的信息。例如，您可以使用它们来区分内部和外部更改。MR 与您应用的特定功能、更改类型或大小相关。使用标签让我能够更轻松地管理合并请求！如何创建标签？

1. 转到github.com并导航到您的存储库
2. 前往Pull request​
3. 点击Labels靠近过滤输入
4. 点击绿色New label按钮
5. 填写表格中的所有字段并点击Create labels按钮

现在，您可以在拉取请求创建表单或拉取请求部分的菜单中将此标签分配给任何新的或现有的合并请求。

3. 自动检查

并非所有内容都能自动测试。但很多事情，例如语法或运行测试，都可以。不要浪费你和同事的时间去检查那些可以用计算机测试的内容。你可以使用 Jenkins/Github Actions/CircleCI 或任何其他你选择的工具，在每次创建合并请求时启动自动化测试。添加一条规则，在所有必需的检查都通过之前禁用合并。这或许有一天能拯救你的生产力！小贴士：还可以添加一种轻松手动重新触发这些测试的方法——例如，在 GitHub 的评论中发送一条特殊消息。这在调试问题时非常有用。

4. 带有清单的拉取请求模板消息

每个合并请求都应该有一个好的、简短的、不言自明的标题和一些描述。在大型团队中，添加其他信息也很有用，例如来自任务跟踪系统（如 Jira 或 Trello）的任务/问题链接。有些事情无法手动测试 - 例如可访问性或满足业务需求。不幸的是，当您的团队和项目不断发展壮大时，作为作者，要记住合并请求消息中要包含的所有内容，以及作为审阅者要检查的内容变得越来越困难。您可以使用合并请求模板轻松解决这些问题。这样，您将看到一个预定义的消息草稿，其中包含创建合并请求时要手动检查的事项清单，只需在表单中填写所需信息并将清单中的所有项目标记为已完成即可。

怎么做呢？

1. 在您最喜欢的代码编辑器中打开您的存储库
2. pull_request_template.md在存储库的根目录或位于根目录中的 docs 文件夹中添加文件。
3. 将模板放入文件中（您可以使用 markdown 语法来创建标题、清单等）。
4. 将更改合并到主分支。

注意：如果您想要创建多个消息模板，请创建PULL_REQUEST_TEMPLATE目录（也可以在根目录或 docs 文件夹中），并将您的 Markdown 文件保存在那里。在此设置下，用户可以在创建 MR 时使用下拉菜单选择其中一个模板。

5. 始终保持开放的心态和同理心

我的最后一条建议并非技术性很强，但却极其重要（灵感来自上面那条推文，推文中描述了4个人击败了5个人，并附有“5个开发人员中有4个喜欢代码审查”的描述）。进行代码审查时，请始终保持开放的心态并强调重点。代码审查并非是为了批评某人的技能。它也不是炫耀你优越性或丰富经验的地方。它是一种让我们所有人共同成长、学习和保持高质量的机制。所以，不要只批评。如果有人做得很好——请让他们知道！如果有人解决问题的方式与你不同，在强迫他们按照你的方式编码之前，请尝试理解他们的方法。如果有人犯了错误——请让他们知道，但要以支持的方式，而不是仇恨的方式。我们每个人都经历过一次教训，有时我们都会犯错。只写下你希望获得的信息——帮助你提升技能，但不要让人感到沮丧。尽管存在刻板印象，但同理心是软件工程中的一项关键技能 ——不要忘记这一点！总而言之，如今编程是一项团队运动。

概括

以下技巧并非详尽无遗地阐述了改进代码审查的所有方法，但在我看来，它们有助于你更好地创建良好的代码审查流程并制定一些标准。希望本文对你有所帮助。如果觉得有用，请点赞或分享给你的朋友。提前致谢，祝你编程愉快！