PR 也就是 Pull Request，是指一次我们对代码改动提交的请求，通常会包含一次或者多次 Commit。PR 主要是为了在软件开发的过程中，方便的对源代码进行有效的 Code Review。
Code Review 也就是我们常说的代码审核，其目的就是为了在同级审核的过程中，找出并修正在开发过程中出现的错误以及不足的地方，以前置的形式保证代码质量，让有问题的代码不会合入主分支，同时提高开发者自身的水平。
Code Review 最早在硅谷盛行，在国内一线的互联网公司，一般也都是重视 Code Review 的。
当你需要提交你的代码改动的时候，你会发布一个 PR，通常你还会指定一些，此次 PR 的代码改动可能会影响到的模块的负责人，来帮你 Review 看看会不会对他们的功能有所影响。一个 PR 发布出去之后，其他工程师就可以在 PR 的页面上提出自己的意见和建议，代码的作者也可以回复这些意见和建议，如果觉得是有效建议，可能就直接修改并提交了，觉得应该坚持自己的意见也可以写下为什么这么修改的理由。
如果你们公司有 Code Review 的文化的话，我想你除了自己会提交 PR 之外，你也需要帮其他同事 Review 他们的 RP。
若是新人的代码，尽可能在代码的方方面面都进行仔细的审查，例如：代码风格、性能等。如果是老员工，在这些方面会多给一些信任，只要思路没问题，通常就不会有太大的问题。
可你有没有发现，有一些人的 PR，阅读起来非常的轻松，让你很快阅读完并不会让你对作者的意思产生歧义。而另外一些 PR，阅读起来就非常的累，感觉很生涩。这一部分在于作者本身代码水平的问题，另外一部分，其实也是有一些经验可以参考的！
为什么有些PR阅读起来会累？
首先我们思考以下，为什么有些 PR 我们阅读起来，会觉得很累？
丹尼尔·卡尼曼在他的《思考，快与慢》里提到，在我们的大脑中，存在两个思维系统，分别为系统 1（快思考）和系统 2（慢思考）。
系统 1 就像大脑的自动反应模式，会根据生活经验总结无数下意识反应的套路，让我们的生活被简化。但是一旦遇到需要思考的问题，系统1 就会向系统 2 求助，系统 2 此时就会将大脑的注意力分配到去解决系统 1 碰到的难题。
系统 2 十分严谨，具有推理能力，它也可以处理多重任务，这也决定了通过系统 2 运作得出的结论往往会更靠谱。但是系统 2 要求我们集中注意力，同时也会更多的消耗精力，会让我们更容易疲惫。
这就是为什么当我们在阅读一本印刷精美的书的时候，会更轻松一些，此时完全是由系统 1 来处理。当你在阅读一本盗版书，碰上一些错别字、不该换行的时候存在换行，此时你的系统 2 就立刻警觉并开始运行，这也就是为什么阅读一本烂书会让我们更累的原因。
Code Review 的时候也是如此，当 PR 观点清晰，代码整洁，无其他会让我们分心的内容的时候，我们阅读起来也只需要通过系统 1 来执行我们对代码的经验套路，让我们阅读代码会变得更轻松。
如何让 PR 更“贴心”
前面也提到，当 PR 里观点清晰，代码整洁，我们阅读起来就会更轻松。
接下来我们说说，在提交 PR 的时候，一些常见的套路，让 Review 的人，感觉更 “贴心”。
1. 保持 PR 的单一性
一次 PR 尽量保证为一次有效的改动，例如修改了某个 Bug、增加了某个功能，一定不要柔和了太多的功能或者 Bug 修复。
当一个 PR 包含多项改动的时候，不仅让 Review 的人感觉抓不住重心，并且还可能会掩盖一些简单的错误。另外还有个问题，如果因为每次 PR 里包含了一些会引起线上问题的代码，可能会导致 PR 被 Revert，这个时候，此 PR 中包含的多项改动，也会同时被 Revert，无形中加大了工作量。
2. 避免全局的代码格式化
有一种“烂 PR”，一个文件只改了一行代码，但是一格式化之后，全文都是改动，这样在 Review 的时候，就很难让我们集中注意力。
虽然格式化的风格，可以通过 IDE 的设置来调整，但是通常这不是强制执行的。
所以我们还是要保持良好的习惯，我建议选中你修改的代码，再进行格式化，也就是仅对你修改的部分进行格式化。这样就可以避免全文件被格式化的问题。
3. commit 前，使用 diff 工具检查此次改动
在开发的过程中，因为种种原因，有时候我们会留下一些并不需要提交的代码片段、或者临时的 Debug 信息之类的代码。这些代码，应该在我们提交之前就清理掉。
而在 commit 之前，使用 diff 工具再次检查一遍此次的改动，是非常好的习惯。
对于 Android Studio 来说，本身已经提供了非常棒的 Version Control 工具，在其中的 Local Changes 窗口里，就包含了我们此次的改动，我们只需要一个个文件扫一遍，去掉我们不必要的改动，再提交即可。
4. 前置的 Lint 检查
如果所维护的项目，做了持续集成，例如 Jenkins 来在每次提交后都 Build 一遍项目，那如果你的代码没有通过 Lint 检查，你可能会在刚 merge 一个 PR 之后，立刻收到一个 "Build failed" 的邮件。
这种邮件一般会发给负责人以及提交代码的你，这种感觉很不好。尤其你作为一个 Review 代码的人，刚点击 "Approve" 某个 PR，然后此 PR 被 Merge 之后，收到一个这样的邮件。我想下一次，再 Review 他的 PR 的时候，就会格外小心一点，小心的看看会不会出现 Lint 不通过的情况。因为这样会显得像是我们做错了什么一样，"我刚刚认同了你，你就出错了"。
所以在提 PR 之前，在当前你的 feature branch 上跑一遍 Lint 的脚本是特别重要的，如果你本机的 Lint 配置和 Jenkins 服务器一致的话，对于单个文件的修改，你也可以尝试使用快键键 F2 来检查单个文件中，可能的代码隐患。
5. 尽早阅读对方的意见并给予回复
一个 PR 发布出去之后，其他工程师就可以在 PR 的页面上提出自己的意见和建议。
我建议，尽早阅读这些建议，并都给予回复。如果采纳对方的建议，就直接按照思路修改代码，并回复“已修改”。当然有一些并非强制的建议，你也可以回复“谢谢建议，但是我觉得我这样处理更好”，并附上理由。
虽然少部分公司会把 Code Review 纳入绩效当中，来显示对 Code Review 的重视。但是通常并不会为工程师额外分配 Code Review 的时间，一般都是通过工作的间隙，来进行 Code Review。
这就带来了一个问题，我此次的评论，两天以后你给我回复，我还需要思考我当时为什么会有这种想法，提了一个这个评论。线程的切换总是要消耗资源的。但是如果在我评论之后，作者立刻给予回复，我就不需要切换上下文就可以很连贯的对这次评论再进行一次思考。
这也是一件可以让人轻松 Review 的事情。
【本文为51CTO专栏作者“张旸”的原创稿件，转载请通过微信公众号联系作者获取授权】
