在多年编写和审查代码的过程中，我学到了一些秘诀来制作更好的拉取请求并更有效地审查代码。 我将所有这些秘密倾注到我的新书 中，但您会在这里找到包含这 13 个技巧的预览，您可以在开发人员活动中使用它们。 Pull Requests and Code Review 你能想到更多的技巧吗？在评论中分享它们😉 1. 在代码可供审核之前创建 PR PR 草稿可帮助您在仍在开发功能时组织您的想法并记录您的进度。 2.让人们想要查看你的公关 获得快速有效审查的最佳方法是让您的 PR 保持小型且有据可查（包含所有必要的上下文）。现在就提供出色的代码，您还可以增加获得未来 PR 的机会！ 在我的免费书 中可以找到所有这些技巧以及更多内容，以及更多现实生活中的示例和可操作的见解。 《Pull Requests and Code Review: Best Practices for Developers, from Junior to Team Lead》 3. 成为你的 PR 的第一位审阅者 将自己置于审阅者的立场上，预测问题，并在您认为可以帮助他们时使用注释您自己的代码。 4. 为您的 PR 分配合适的审阅者 不要将你的 PR 分配给整个世界。仔细选择您的审阅者以获得相关审阅，而无需等待太长时间获得批准。 5. 积极回应评论 对反馈持开放态度，要求澄清，表达你的不同意见（尊重），并始终回应评论。 6. 如果你想让人们审查你的 PR，你就必须审查他们的 PR 每个人都有很多 PR 需要审查，但空闲时间却很少。如果您审阅其他 PR，您的 PR 也将获得审阅的机会。 7. 即使你是初级开发人员也可以审查代码 作为初级开发人员，当您不理解部分代码时，您可以让其他人知道，因为团队中的任何开发人员都应该可以理解。 有关更多信息，请参阅我的文章 。 如何作为初级开发人员进行代码审查？ 8. 在代码审查期间检查正确的事情 代码审查的目标是检查错误和边缘情况，并对实施提出挑战。它既不应该被用来挑剔次要的格式或样式偏好，也不应该被用来进行大规模的架构讨论。 9. 在评论中使用正确的语气 使用“为什么不”而不是“你应该”，保持开放和积极的态度，并在要求改变时始终提出替代方案。 10. 明确是否需要进行变更才能批准 PR 并非所有评论都需要更改，也并非所有要求的更改都需要 PR 获得批准。如果更改不紧急，请在评论中明确说明。 11. 在提交之前检查您的评论 在公开您的评论之前，请重新阅读每条评论：检查您使用的语气，并确保您提供了所有上下文来帮助 PR 提交者。 12. 当提交者完成您要求的所有更改后批准 PR 您不希望审阅者在完成您要求的所有更改后两天等待您的批准。当您审查它时，假设您会在所有修复完成后立即批准它。 13.有些冲突无法在评论中解决 当评论线程成为 PR 中的争论时，您最好将其切断并建议在其他地方继续讨论，例如在 Slack 线程中。如有必要，专门召开一次会议，和/或让第三方参与。 就是这样！您对这些建议有何看法？您能想出一个您想给其他开发人员的建议吗？ 在评论中分享吧👇 如果您喜欢这些技巧并想了解更多信息，请查看我的书 ，它是免费的！ Pull Requests and Code Review 也发布 。 在这里
