下载掌阅APP，畅读海量书库
立即打开
Pull Request是在所有类型的代码上进行协作的好方法。本章只触及协作工作流的可能性的表面，但是为了让团队有效协作，读者应该考虑一些有效代码评审的最佳实践。
这一点可能看起来理所应当，但要确保团队在Git方面训练有素。与随机分布在多个提交中的许多更改相比，具有良好提交注释且仅服务于一个目的的精细的提交更易于审阅。特别是将重构和业务逻辑混合在一起会使审阅成为一场噩梦。如果团队成员知道如何修改提交、修补他们在不同提交中所做的更改，以及如何撰写良好的提交消息，那么最终的Pull Request将更易于审阅。
将Pull Request链接到启动工作的相应issue。这有助于为Pull Request赋予背景。如果使用第三方集成，请将Pull Request链接到Jira、Azure Boards工作项或已连接到GitHub的任何其他源。
让团队成员在开始处理某项工作时立即创建一个Pull Request草稿。这样，团队就知道谁在做什么。这也鼓励人们在审阅开始之前使用带有提示的注释来征求反馈。尽早对更改进行反馈有助于在最后进行更快的审阅。
至少需要两名审批者，当然人数越多越好，具体取决于团队规模，但一个是不够的。拥有多个审阅者会使审阅具有某种动态性。作者注意到一些团队的审阅有很大成效，这仅仅是由于把审批者从一个变成了两个！
将审阅视为同级审阅。不要让高级架构师审阅其他人的代码！年轻的同事也应该通过同级审阅来学习。一个好的方法是将整个团队添加为审阅者，并要求一定比例的批准（例如50%），然后人们选择他们想要的Pull Request。或者可以使用自动审阅在团队中随机分配审阅。
许多审阅步骤可以自动化，尤其是格式设置。使用linter检查代码的格式（可参见https//github.com/github/super-linter），或者编写一些测试来检查文档是否完整。使用静态和动态代码分析自动查找问题。更多地自动化琐碎的检查，就能将更多的审阅集中在重要的事情上。
合并前自动构建和测试更改。如有必要，使用代码进行测试。人们越是相信改变不会破坏任何东西，他们就越是信任改变这个过程。如果所有审批和验证均通过，则在进行自动合并后发布更改。高度自动化使人们只需要关注较小的批量，这使得审阅变得容易得多。
一些工程师对某些需求的正确做法很有自己的想法，因此很容易发生激烈的争论。如果希望进行激烈的讨论以获得最佳解决方案，但又希望这些讨论以包容的方式进行，以便团队中的每个人都能平等地参与，制定审阅准则和行为守则有助于达到这一目的，如果人们行为不当，可以通过规则指出错误。