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