编写清晰的代码只是在创建 Pull Request 时您应该关注的众多因素之一。
大型 Pull Request 会在代码审查期间造成很大的开销，并可能在代码库中引入错误。
这就是为什么你需要关注 Pull Request 本身。它应该简短，标题和描述清晰，并且只做一件事。
为什么你应该关注？
- 一个好的 Pull Request 会被快速审查
- 它减少了将错误引入代码库
- 它方便了新开发人员的入职
- 它不会阻塞其他开发人员
- 它加快了代码审查过程，从而加速了产品开发
Pull Request 的大小
识别有问题的 Pull Request 的第一步是寻找大型差异。
多项研究表明，在审查大量代码时，更难找到错误。
此外，大型 Pull Request 会阻塞可能依赖于该代码的其他开发人员。
我们如何确定完美的 Pull Request 大小？
一项思科系统编程团队的研究表明，在 60 到 90 分钟内审查 200-400 行代码应该可以发现 70-90% 的缺陷。
考虑到这个数字，一个好的 Pull Request 不应超过 250 行代码的更改。
图片来自 small business programming。
如上图所示，超过 250 行更改的 Pull Request 通常需要一个多小时才能审查。
将大型 Pull Request 分解为较小的 Pull Request
功能分解是一门艺术。你做得越多，它就变得越容易。
我所说的功能分解是什么意思？
功能分解是理解一个大的功能，并将其分解为有意义的小块，这些小块可以逐个合并到代码库中而不会破坏任何东西。
从实践中学习
假设您需要在您的应用程序上创建一个订阅功能。它只是一个接受电子邮件地址并保存它的表单。
在不了解您的应用程序如何工作的情况下，我已经可以将其分解为八个 Pull Request
- 创建一个模型来保存电子邮件
- 创建一个路由来接收请求
- 创建一个控制器
- 创建一个服务以将其保存在数据库中（业务逻辑）
- 创建一个策略来处理访问控制
- 创建一个订阅组件（前端）
- 创建一个按钮来调用订阅组件
- 在界面中添加订阅按钮
正如您所看到的，我将此功能分解为多个部分，其中大部分可以由不同的开发人员同时完成。
单一职责原则
单一职责原则 (SRP) 是一项计算机编程原则，它规定每个模块或类都应该只负责软件提供的功能的一个部分，并且该责任应该完全由该类封装。
就像类和模块一样，Pull Request 应该只做一件事。
遵循 SRP 可以减少因修改尝试解决多个问题的代码而造成的开销。
在提交 PR 进行审查之前，尝试应用单一职责原则。如果代码做了不止一件事，请将其分解为其他 Pull Request。
标题和描述很重要
在创建 Pull Request 时，您应该关注标题和描述。
想象一下，代码审查员今天加入您的团队，但不知道发生了什么。他应该能够理解这些更改。
一个好的标题和描述是什么样的
上图显示了一个好的标题和描述是什么样的。
Pull Request 的标题应该是自解释的
标题应该明确说明正在更改的内容。
这里有一些例子
编写有用的描述
- 描述 Pull Request 中更改了什么
- 解释为什么存在这个 PR
- 明确说明它是如何实现其目标的——例如，它是否更改了数据库中的列？这是如何完成的？旧数据会发生什么？
- 使用屏幕截图来演示已更改的内容。
总结
Pull Request 大小
Pull Request 必须最多有 250 行更改。
功能分解
尽可能将 Pull Request 分解为较小的 Pull Request。
单一职责原则
Pull Request 应该只做一件事。
标题
创建一个自解释的标题，描述 Pull Request 的作用。
描述
详细说明更改了什么、为什么更改以及如何更改。
本文最初发布在 Medium 上。经许可转载。
4 条评论