转载

关于Pull Request的十个建议

Pull Request 是 Bitbucket 、 GitHub 等源代码托管系统为了方便开发者之间协作而提供的一个功能，它提供了一个用户友好的 Web 界面来帮助审查人员进行代码审查。开发人员可以通过 GitHub 发出 Pull Requests 要求请求他人将程序拉下来进行代码审查。一个好的 Pull Request 不仅仅只是代码的事情，还牵涉到代码审查者对代码的审查，所以开发者不仅要写出好的代码，还必须迎合审查者的审查工作，才能给使得自己贡献的代码顺利通过审查并合并到 master 分支。现对丹麦的程序员、软件架构师、独立顾问 Mark Seemann 在自己博客中发布的一篇题为《关于 Pull Request 的十个建议》的文章进行一个全面的整理，以供读者阅读和参考。具体内容如下：

1. 进行较小的 Pull Request

一个小且集中的 Pull Request 会使得提交的代码更加容易通过审核。据 Mark Seemann 根据自己的经验透漏，对提交代码进行审查所花费的时间是随着代码大小呈指数增长，而非线性增长；Pull Request 多大才合适与 Pull Request 做了什么相关，最好少于 12 个文件的改变。如果 Pull Request 非常大，审查者就需要安排连续、相对比较长的时间进行审查，就会造成审查过程的延迟。

2. 每个 Pull Request 只做一件事

就如软件设计模式中的单一责任原则所指：一个类只负责一个功能领域中的相应职责，因此一个 Pull Request 也应只关注一件事情。如果一次 Pull Request 做了多件事情的话，将会增加审查过程的延迟、审查被拒绝的可能性。

3. 注意代码行的字数，最好少于 80 个字

代码审查者会使用不同的审查工具来审查提交的代码，并且 GitHub 和 Stash 还提供了不同形式的视图，这样就使得代码审查者能通过不同视图非常方便来审查用户的提交。如果代码行比较宽的话，审查者就不能在一个屏幕或者半个屏幕中来阅读代码，不得不拖动滚动条来阅读代码。为了使得代码比较容易审查，每行代码最好少于 80 个字符。

4. 避免重新格式化代码

就算自己觉得应该改变当前代码的格式以适合自己的风格，但是请不要这么做。在源代码上，用户对每个字节的改变将会在不同的审查视图显示出来。有些审查者会选择忽略空格改变，但是有些审查者会审查这些代码，对这些格式化引起的代码审查属于不必要的审查。如果真需要解决空格问题的话，就需要在其他文件里移动代码、改变格式或者对代码做其他样式改变，并在 Pull Request 注释中给出相应的说明。