编写清晰的代码只是在创建 pull request 时您应该关心的众多因素之一。
大型 pull request 会在代码审查期间造成很大的开销，并可能导致代码库中出现 bug。
这就是为什么您需要关心 pull request 本身。它应该简短，有清晰的标题和描述，并且只做一件事。
为什么要关心？
- 好的 pull request 将会得到快速审查
- 它可以减少将 bug 引入代码库
- 它有助于新开发人员入职
- 它不会阻止其他开发人员
- 它可以加速代码审查过程，从而加速产品开发
Pull Request 的大小
识别有问题的 pull request 的第一步是查看大的差异。
多项研究表明，在审查大量代码时，更难发现 bug。
此外，大型 pull request 会阻止可能依赖于该代码的其他开发人员。
我们如何确定完美的 pull request 大小？
对思科系统编程团队的一项研究表明，在 60 到 90 分钟内审查 200-400 行代码应该可以实现 70-90% 的缺陷发现率。
考虑到这个数字，一个好的 pull request 不应有超过 250 行代码的更改。
图片来自 小型企业编程。
如上图所示，更改超过 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 条评论