在 Pull Requests 中成为摇滚明星

在我的职业生涯中，我审核过数千个拉取请求。以下是我在构建包容性学习环境的同时，如何创造价值的一些建议。

致作者和审稿人

保持小规模和迭代式开发。专注于目标，可以让审阅者提供及时、高效的审阅。这很难，但要避免批量处理工作。

使用标签来表明意图。无论是使用主题行中的前缀，还是如果工具支持标签功能，都应大量使用这些标签来表明工作正在进行中、审核规模大小或与某个里程碑相关。

请提供清晰的背景信息。在拉取请求的描述中定义问题和解决方案。这将为评审提供极大的价值，并包含有助于其他成员快速上手的历史信息。

审阅你的提交记录并在评审中提供评论。立即自我审阅你新提交的拉取请求，以减少歧义。主动为需要澄清的代码行提供摘要内容，以便评审者能够清晰地了解上下文。

始终保持开放的心态接受反馈。审阅者很可能出于好意。要认真对待反馈，可以提出问题并进行建议性的修改，或者双方协商后再处理。尊重他人的审阅意见才是有益的。

用工具记录对话。很多时候，围绕拉取请求都会展开讨论。然而，其他人却无法了解这些信息。请跟进讨论，并将结果记录在工具中。这样做能极大地帮助其他人理解上下文。

最后以认可和总结性评语结束，表明评审完成。在评审的结尾，添加一个总结段落。反馈将概括评审过程，鼓励作者的出色工作，并建立评审者和作者之间的信任。

富有同理心的评论能起到锦上添花的作用。展现你对代码和作者的真挚关怀。将你的建议性修改添加到拉取请求的顶部。这种持续的礼貌有助于建立协作团队。

优先选择结对编程而非提交拉取请求。结对编程与完整的拉取请求效果相同，但可以实时进行。努力构建一个系统，以便在结对编程充分的情况下，能够让参与者以高度简洁的方式合并代码。

让所有人都能及时获得代码审查。让新手也能轻松参与代码审查流程，及时获得审查意见。我见过一些团队设定了具体的审查时间范围，另一些团队则设定了服务级别协议 (SLA)。无论采用哪种方式，都要保持包容和友好。审查者负责拉取代码，作者无需推动。

始终致力于改进工具，避免吹毛求疵。高带宽的拉取请求更注重代码库的方向，而非格式。持续投资工具，让人工审查发挥最大效用。每一个细小的评论（吹毛求疵）都是一次自动化消除的机会。

欣然接受待办事项。拉取请求最大的价值在于潜在的改进机会。捕捉它们，拥抱它们，热爱它们。最重要的是，跟踪它们，并在下一次迭代中完成它们。

不断完善描述性模板。有些团队有自己提交 pull request 的原则。我见过一些团队使用清晰的清单，确保 pull request 内容全面完整。找到一个有助于完善 pull request 的工具。

让本地运行工作变得轻松便捷。避免构建失败带来的意外情况。在本地模拟拉取请求中的所有操作。无论是预提交、静态分析还是测试，都要确保任何人都能通过一条命令轻松运行构建。

鼓励循序渐进，而非设置门槛。要始终关注代码库的健康状况，并确保抽象概念易于理解。不要追求完美；要期待每次代码审查都能带来学习和进步。记住，团队中有各个级别的工程师。你是否在帮助他们成长的同时，避免了挫败感？

Pull Request 的目的是促进交叉学习。尊重他人 Pull Request 中的努力。软件工程以上下文和观点为主导。务必让作者明白这些理念。明确的期望是良好合作关系的基础。贡献指南可以作为入门参考。代码审查的附带好处包括发现 bug 和保持代码一致性。

保持乐趣。我曾经观察过一个团队，他们挑战自我，在每份摘要中都写出妙趣横生的俳句和散文。反复练习成百上千次，最终打造出了一支堪比海明威的团队。不妨也培养一下这种玩乐的习惯。工程的精髓就在于好奇心和寓教于乐。