什么是好的 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 工具檢查此次改動
在開發的過程中，因為種種原因，有時候我們會留下一些并不需要提交的代碼片段、或者臨時的 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專欄作者“張旸”的原創稿件，轉載請通過微信公眾號聯系作者獲取授權】
