人性化拉取请求 (PR) 的艺术

什么是 PR，如何有效地创建 PR，如何对 PR 提供反馈以及如何回应反馈

什么是拉取请求（PR）？

PR 是更改代码库中代码的请求。一旦你对代码进行了必要的更改，就可以提交 PR。提交后，相关方将进行代码审查，并向你提供任何必要的反馈/更改。

拉取请求通常由团队用于共享协作、功能开发或错误修复。其目的是确保将编写良好且无错误的代码推送到代码库。这是一种开发高质量代码的方法。

如何创建拉取请求

分解你的故事/专题

在开始编写一个故事/功能之前，请在心里/写下你希望如何将其分解成几个较小的 PR。这不仅对审阅者有帮助，也对你自身也有帮助，因为你可以跟踪进度并频繁获得反馈。另一个好处是，由于代码库与其他开发者共享，撤销更改会变得更加容易。因此，在分解 PR 时，请尽量将其范围限制在单个问题上。

例如，假设您正在实现待办事项列表并有以下故事：

作为用户，我可以分别在列表中添加和删除项目

我会将其分解如下：

PR #1：在页面上添加一个文本框和一个添加按钮。PR

#2：点击“添加”按钮可将项目添加到列表中。PR

#3：点击列表项上的“删除”按钮可将该项目从列表中删除。

这样做你会得到审阅者的祝福🙏。想象一下，如果你的同事爆出了一个超级大的 PR，你肯定不想去审阅，对吧？🙈

在您的 PR 上添加评论

通常情况下，无论你在哪里做了一些不同的事情，最好在行号处添加注释，解释你这样做的原因。如果你对自己的代码不太确定，一定要给那些最了解该代码的人打上“@”标签，以获得反馈。例如，

您使用了Lodash库中一个新函数，该函数isNan可能在代码库中不常用，您可能想在那里添加一条注释this function basically checks if the value is Nan and returns a boolean。

这对审阅者有很大帮助，因为这节省了他们的时间（即如果他们还不知道该功能的作用）。

添加屏幕截图/gif

截图和动图可以证明你提交的代码是有效的！这不仅能增加代码被接受的可能性，还能让审阅者直观地了解你实现的代码。截图当然有用，但如果代码的功能超出了截图的范畴，可以创建动图。使用动图，你可以点击查看 PR 涵盖的所有内容。我最喜欢的动图是：Licecap 🔗

测试是代码的文档

每当你完成了一些对你来说有意义的事情，并想向未来的开发人员解释这段复杂的代码时，你对特定修改的意图是什么？不要在代码中堆砌代码注释，问问自己这些问题：如果理解起来如此困难，

• 我可以将此代码拆分成更小的函数吗？
• 我可以将这个函数重命名为更明显的名称吗？如果愿意，请向您的团队询问函数名称建议。
• 我怎样才能进一步简化我的代码，以免它变得复杂？

无论你选择什么，你都应该写一个测试。🔥

测试不仅用于测试你的逻辑，同时也是代码的文档。尝试添加一个测试来解释代码的这一部分。

如何审查 Pull 请求？

富有同理心

作为评审员，以礼貌的方式提供反馈至关重要。你需要记住，你评审的是你的队友的代码，你喜欢和他们交流，一起出去玩、吃午餐等等。他们是人，有感情，而感情很容易受到伤害！💥因此，在评审时要更具同理心。

让自己更熟悉代码

无论你是初级还是高级开发人员，都要养成教导的习惯。与其直接告诉他们问题所在，不如用友善的语气提问，引导他们思考。以下是一些例子：

• 您认为我们可以将其分配给变量并在第 9 行重新使用它吗？
• 我们可以使用我们亲爱的队友莎拉构建的这个有用的实用程序来为我们做到这一点吗？
• 我们可以将此代码移到其自己的函数中，以便我们可以编写更多测试吗？
• 您觉得尝试此选项怎么样🤔？
• 我不确定我是否理解了全部内容 ，但你能解释一下这个函数的作用吗？这样他们可能会认为这个函数名可以重命名。在他们解释完它的作用后，再提出一些建议，例如：

我明白了，抱歉回复慢了！我不太确定，不过你觉得我们可以把这个函数改成 option1、option2 或者类似的名称吗？你觉得怎么样？

一定要询问他们的想法，因为请记住你是一名审阅者，他们编写了代码，所以他们可能比你拥有更多的背景信息。

想象一下，如果你的同事说了这样的话：“别这么做，直接重命名函数就行了”。这听起来太直接了，不太友好，而且听起来像是在给他们下命令，而不是在听取他们的意见。

始终提供代码改进建议

不要只是告诉他们“这段代码还有改进空间”。要提供一些建议/示例，告诉他们如何进一步改进，例如：

这段代码运行得很好，但当我进一步阅读之后，我又想到了另一个想法，想让你运行一下。我不太确定，但你觉得怎么样？

示例代码 #1，

示例代码 #2，

你觉得怎么样？

使用表情符号

网上的批评很容易被误解。因此，表情符号是在线交流的最佳工具之一。使用表情符号会自动为你的句子增添友好的语气。当你觉得谈话变得过于严肃时，可以使用表情符号 。但如果你并非如此，就不要勉强，保持真实。

离线

如果你发现自己和队友的对话来回反复，对话时间过长，而且毫无进展，那就把对话线下化吧。如果你可以快速接听电话🤙或者直接走到他们的办公桌🚶‍，那就没必要花时间打字了。

当你们面对面交流时，你自然会更加感同身受，进一步理解对方的观点，反过来，对方也会理解你的观点。当你得出结论时，在 PR 上发布一条评论，总结你们的讨论，这样其他关注的读者就能注意到，未来的你也会因此感谢你。

挑剔

在代码审查过程中，你可能会发现一些本质上是吹毛求疵的地方，也就是说，它不一定会影响 PR 的批准，但需要注意。吹毛求疵的地方并不重要，但技术上是正确的。它们可能与语法更正、无意添加的新行、任何美观问题、细微的代码重构等有关。例如，

nit：额外的空白

nit：我们可以将这个值分配给 aconstant以提高可读性吗？

如何回应反馈

提交 PR 时适用的规则同样适用于回应 PR 时。

当提出建议时

永远记住，你正在与他人协作，编写代码。如果有人提出建议，请务必将其视为改进代码的可能性。如果你有任何不明白的地方，请寻求帮助，例如：

你能举个例子吗？或者你能进一步解释一下吗？我不太明白。

如果您认为反馈有效，就采纳它！无论修改大小，如果您认为反馈有效，请务必回复并告知审核人您已采纳他们的反馈。例如，

你的观点太棒了，改变马上就来了！

说得好，谢谢你注意到了。

如果你不同意👈

由于不同的开发人员编写代码的方式不同，分歧难免会发生。不过，请尽量以非常友好的方式表达您的意见。如果您部分同意他们的观点，请告知他们，并在不同意的地方提供您的理由。例如，

说得太好了。我完全同意你的第一个建议，会立即修改。我完全忽略了这一点。不过对于第二个建议，我确实考虑过这个选项，但最终决定不这么做，因为在以下情况下，我们不想显示它。//或者无论你的理由是什么，请说实话。👈

让你的提交信息显而易见

既然你已经花时间准备了反馈，那就写一条好的提交信息，让审阅者知道你确实考虑了他们的反馈，但不要写得太长。🔗 Gitmoji是一个非常方便的工具。😍 它们提供了一种简单的方法，可以通过查看使用的表情符号来识别提交的目的或意图。

更进一步

您根据收到的反馈对代码进行了一些修改。现在，您的代码可以处理一个您之前没有想到、没有意识到或可能忽略的额外场景，但您现在有机会“编写测试”。

代码合并后，缺陷就会被填补。修复该缺陷后，添加测试以确保缺陷确实已修复，并且有证据🕵️‍。现在，它已经记录在案了！！😃 如果你更进一步，就能获得加分🍫。你自然会赢得团队的信任。

希望你喜欢这篇文章，并且有所收获。如果喜欢，请点个赞❤️。也欢迎在评论区留言，分享你对 Pull Request 的个人体验。如有任何疑问，欢迎随时通过我的 Twitter 联系我。