什么是好的 PR？它能让你更靠谱！

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 工具检查此次改动