如何有效地打开拉取请求

拉动请求是任何推送代码的世界级科技公司的必备工具。 它可以确保您的代码正在由其他工程师审核，并增强了被审核者对他们的代码符合工程团队所同意的一组标准的信心。 但是就像每杯️☕一样，质量在PR中扮演着重要角色。 质量低劣的公关人员可能会使被审核者和审稿人的口感不好，这通常是由于抨击和非建设性的反馈造成的。 它可能导致工程师之间的不信任和烦恼，直接影响代码库，甚至影响公司的文化。 但是，有效的PR可以引发有关最佳实践，代码约定和团队标准的良好有机对话。 PR中的代码修改将影响当前和将来形式的代码库。 最终，每个被批准和合并的PR都是构建产品和公司的LEGO块。 考虑到这一点，工程师确定如何打开有效PR的要点非常重要。 有效的公关人员应该就思想共享，最佳实践，工程惯例和团队团结进行对话。 创建有效的PR似乎是一项琐碎的任务，但是许多工程师陷入了不良习惯，甚至没有意识到。 这里有一些技巧，以提高您的PR游戏。

保持拉短要求

在审查代码之前，您如何惹恼其他工程师？ 使用10,000行以上的代码更改来打开大型请求。 眼疲劳，背痛和偏头痛只是工程师在滚动巨大PR时遇到的一些副作用。 让您的公关简短，简单，切合实际。 从历史上看，大型PR通常会被迅速批准并合并，因为审阅者会在代码中略过一遍，没有任何评论可望结束滚动。 如果团队完全不关心代码库的健康状况，但是如果您的团队追求质量和维护，请打开小而简洁的PR，作为附带的好处，您的审阅者会感谢您。 公关应该改变多少行没有神奇的数字，但是如果您在跟踪或描述代码在一个句子中的工作时遇到困难，请分拆公关。 另一个好的经验法则是，票证与PR之间的比例为1：1，并且如果票证看起来太大而不能将其分解为子任务票证，则可以确保较小的PR。 请记住，易于阅读的PR假定可以在工程师之间产生良好的对话和协作。 PR不能用于跟踪谁可以更改回购中的大多数线路。 具有较大PR的另一个副作用是，由于分支修改的文件很多，因此需要不断进行重新编制基准，以使分支保持最新状态。 保持简短简短是游戏的名称。

保持评论的建设性

收到非建设性和不完整的反馈是很普遍的，它会使工作贬值，并且不会使有关各方受益。 一些评论甚至看起来更好，因为它可能冒犯或侮辱了打开PR的工程师。 留下建设性的反馈会引起良好的对话。 在评论PR时，有以下一些注意事项：

• 不要告诉工程师您将如何实施该解决方案。 大家都知道有很多方法可以解决。 仅仅因为审阅者可以用另一种方式来做并不意味着工程师必须以某种方式来实现它。 只要代码遵循一组团队惯例和体系结构，就可以为它开绿灯。
• 不要过多地关注代码样式，例如多余的空格，而将其他代码放在换行符上。 将这些任务留给小子而不是人眼看。 不要浪费精力查找丢失的代码样式，而要专注于实际的实现。
• 给予积极的反馈。 给予积极的反馈会鼓励您的工程师。 收到建设性的反馈是很棒的，但是太多的反馈仍然会使被审核者感到束手无策。 我们所有人都打开了PR，以解决一个难题，同情您的被审核者，并告诉他们他们在重构方面做得很好，或者感谢他们修复了一段时间以来令人讨厌的错误。
• 请勿使用“只是”或“我以为我告诉过你……”之类的词或短语。 这些短语可能意味着受审者应该已经了解了一些事实，但未能使用此知识，而在大多数情况下，受审者对此一无所知。 通过暗示一些标准，可以使他们感到过时和沮丧。 相反，请教您的同事工程师，并为他们指出正确的方向。 每个人都喜欢可以教书，学习并保持友善的工程师。 以下是移情评论的一些示例：

而不是 “仅使用用户模型工厂”， 而是 使用 “签出用户模型工厂，那里的某个功能可能会帮助您尝试完成”

代替 “我不是告诉您不要分配这个Car对象”， 而是 使用 “我们分配这个Car对象的原因是什么？ 您如何看待这个重构？”

而不是 “您为什么这样做？ 这是怎么回事？” 使用 “让我们在此片段上进行同步，以进一步了解票证规格。”

• 当您不理解代码片段时，请不要提出问题。 如果您有问题，其他工程师也可能会遇到类似的问题，并且代码可能不够清晰，无法描述其要完成的任务。
• 看到代码气味时，请提供其他解决方案。 当您在PR中看到危险信号时，不要只留下没有方向的评论。 保持被审者的猜测并使他们无路可走，根本就没有扮演团队合作者的角色。 提出想法并就解决方案进行协作，这就是推动有效公关活动的原因。

• 没有无关的公关对话。 公关，如果做得正确，是很好的文档形式，如果您在阅读公关历史时不得不阅读某人的晚餐计划，那将被破坏。 使其与修改的代码直接相关。 不要去看牙医。

添加拉取请求说明

不要忘记提供有关PR正在完成的工作的详细说明。 在没有上下文的情况下阅读代码片段可能会令人沮丧，尤其是在PR较大的情况下。 留下几句话描述您的最终目标是什么。 指定PR是功能，错误还是杂项？ 该功能是要向所有人推出还是仅向选定目标推出？ 如果前端与代码修改有关，则生成屏幕截图或gif可能会提供更多的视觉帮助。 使用模板也是确保被评审者不会忘记提供描述的好方法。 最后，提供指向相应票证的链接可以使审阅者更深入地研究细节。

注意打开有效的PR，您应该开始注意到更好的工程经验。 不要让你的自我接管你的公关工作，并与其他工程师一起工作。 请记住，代码库是团队的产物和反映，如果您想要质量，请彼此协作而不是相互竞争。 互相教，并在需要时提供指导。 快乐的编码。

感谢您阅读本博客，我相信您可能会从自己的经验中获得更多指导。 通过发表评论，在@ ginowu07上发推文或链接来随意分享他们的内容 https://www.linkedin.com/in/gino-wu-60baba67

特别感谢Stash iOS工程团队在迭代我们的PR流程上花费的所有辛勤工作，并感谢 Annie H. Lee 提供图像。