什么是好的 PR？它能讓你更靠譜！
PR 也就是 Pull Request，是指一次我們對(duì)代碼改動(dòng)提交的請(qǐng)求，通常會(huì)包含一次或者多次 Commit。PR 主要是為了在軟件開發(fā)的過(guò)程中，方便的對(duì)源代碼進(jìn)行有效的 Code Review。
Code Review 也就是我們常說(shuō)的代碼審核，其目的就是為了在同級(jí)審核的過(guò)程中，找出并修正在開發(fā)過(guò)程中出現(xiàn)的錯(cuò)誤以及不足的地方，以前置的形式保證代碼質(zhì)量，讓有問(wèn)題的代碼不會(huì)合入主分支，同時(shí)提高開發(fā)者自身的水平。
Code Review 最早在硅谷盛行，在國(guó)內(nèi)一線的互聯(lián)網(wǎng)公司，一般也都是重視 Code Review 的。
當(dāng)你需要提交你的代碼改動(dòng)的時(shí)候，你會(huì)發(fā)布一個(gè) PR，通常你還會(huì)指定一些，此次 PR 的代碼改動(dòng)可能會(huì)影響到的模塊的負(fù)責(zé)人，來(lái)幫你 Review 看看會(huì)不會(huì)對(duì)他們的功能有所影響。一個(gè) PR 發(fā)布出去之后，其他工程師就可以在 PR 的頁(yè)面上提出自己的意見和建議，代碼的作者也可以回復(fù)這些意見和建議，如果覺得是有效建議，可能就直接修改并提交了，覺得應(yīng)該堅(jiān)持自己的意見也可以寫下為什么這么修改的理由。
如果你們公司有 Code Review 的文化的話，我想你除了自己會(huì)提交 PR 之外，你也需要幫其他同事 Review 他們的 RP。
若是新人的代碼，盡可能在代碼的方方面面都進(jìn)行仔細(xì)的審查，例如：代碼風(fēng)格、性能等。如果是老員工，在這些方面會(huì)多給一些信任，只要思路沒問(wèn)題，通常就不會(huì)有太大的問(wèn)題。
可你有沒有發(fā)現(xiàn)，有一些人的 PR，閱讀起來(lái)非常的輕松，讓你很快閱讀完并不會(huì)讓你對(duì)作者的意思產(chǎn)生歧義。而另外一些 PR，閱讀起來(lái)就非常的累，感覺很生澀。這一部分在于作者本身代碼水平的問(wèn)題，另外一部分，其實(shí)也是有一些經(jīng)驗(yàn)可以參考的！
為什么有些PR閱讀起來(lái)會(huì)累？
首先我們思考以下，為什么有些 PR 我們閱讀起來(lái)，會(huì)覺得很累？
丹尼爾·卡尼曼在他的《思考，快與慢》里提到，在我們的大腦中，存在兩個(gè)思維系統(tǒng)，分別為系統(tǒng) 1（快思考）和系統(tǒng) 2（慢思考）。
系統(tǒng) 1 就像大腦的自動(dòng)反應(yīng)模式，會(huì)根據(jù)生活經(jīng)驗(yàn)總結(jié)無(wú)數(shù)下意識(shí)反應(yīng)的套路，讓我們的生活被簡(jiǎn)化。但是一旦遇到需要思考的問(wèn)題，系統(tǒng)1 就會(huì)向系統(tǒng) 2 求助，系統(tǒng) 2 此時(shí)就會(huì)將大腦的注意力分配到去解決系統(tǒng) 1 碰到的難題。
系統(tǒng) 2 十分嚴(yán)謹(jǐn)，具有推理能力，它也可以處理多重任務(wù)，這也決定了通過(guò)系統(tǒng) 2 運(yùn)作得出的結(jié)論往往會(huì)更靠譜。但是系統(tǒng) 2 要求我們集中注意力，同時(shí)也會(huì)更多的消耗精力，會(huì)讓我們更容易疲憊。
這就是為什么當(dāng)我們?cè)陂喿x一本印刷精美的書的時(shí)候，會(huì)更輕松一些，此時(shí)完全是由系統(tǒng) 1 來(lái)處理。當(dāng)你在閱讀一本盜版書，碰上一些錯(cuò)別字、不該換行的時(shí)候存在換行，此時(shí)你的系統(tǒng) 2 就立刻警覺并開始運(yùn)行，這也就是為什么閱讀一本爛書會(huì)讓我們更累的原因。
Code Review 的時(shí)候也是如此，當(dāng) PR 觀點(diǎn)清晰，代碼整潔，無(wú)其他會(huì)讓我們分心的內(nèi)容的時(shí)候，我們閱讀起來(lái)也只需要通過(guò)系統(tǒng) 1 來(lái)執(zhí)行我們對(duì)代碼的經(jīng)驗(yàn)套路，讓我們閱讀代碼會(huì)變得更輕松。
如何讓 PR 更“貼心”
前面也提到，當(dāng) PR 里觀點(diǎn)清晰，代碼整潔，我們閱讀起來(lái)就會(huì)更輕松。
接下來(lái)我們說(shuō)說(shuō)，在提交 PR 的時(shí)候，一些常見的套路，讓 Review 的人，感覺更 “貼心”。
1. 保持 PR 的單一性
一次 PR 盡量保證為一次有效的改動(dòng)，例如修改了某個(gè) Bug、增加了某個(gè)功能，一定不要柔和了太多的功能或者 Bug 修復(fù)。
當(dāng)一個(gè) PR 包含多項(xiàng)改動(dòng)的時(shí)候，不僅讓 Review 的人感覺抓不住重心，并且還可能會(huì)掩蓋一些簡(jiǎn)單的錯(cuò)誤。另外還有個(gè)問(wèn)題，如果因?yàn)槊看?PR 里包含了一些會(huì)引起線上問(wèn)題的代碼，可能會(huì)導(dǎo)致 PR 被 Revert，這個(gè)時(shí)候，此 PR 中包含的多項(xiàng)改動(dòng)，也會(huì)同時(shí)被 Revert，無(wú)形中加大了工作量。
2. 避免全局的代碼格式化
有一種“爛 PR”，一個(gè)文件只改了一行代碼，但是一格式化之后，全文都是改動(dòng)，這樣在 Review 的時(shí)候，就很難讓我們集中注意力。
雖然格式化的風(fēng)格，可以通過(guò) IDE 的設(shè)置來(lái)調(diào)整，但是通常這不是強(qiáng)制執(zhí)行的。
所以我們還是要保持良好的習(xí)慣，我建議選中你修改的代碼，再進(jìn)行格式化，也就是僅對(duì)你修改的部分進(jìn)行格式化。這樣就可以避免全文件被格式化的問(wèn)題。
3. commit 前，使用 diff 工具檢查此次改動(dòng)
在開發(fā)的過(guò)程中，因?yàn)榉N種原因，有時(shí)候我們會(huì)留下一些并不需要提交的代碼片段、或者臨時(shí)的 Debug 信息之類的代碼。這些代碼，應(yīng)該在我們提交之前就清理掉。
而在 commit 之前，使用 diff 工具再次檢查一遍此次的改動(dòng)，是非常好的習(xí)慣。
對(duì)于 Android Studio 來(lái)說(shuō)，本身已經(jīng)提供了非常棒的 Version Control 工具，在其中的 Local Changes 窗口里，就包含了我們此次的改動(dòng)，我們只需要一個(gè)個(gè)文件掃一遍，去掉我們不必要的改動(dòng)，再提交即可。
4. 前置的 Lint 檢查
如果所維護(hù)的項(xiàng)目，做了持續(xù)集成，例如 Jenkins 來(lái)在每次提交后都 Build 一遍項(xiàng)目，那如果你的代碼沒有通過(guò) Lint 檢查，你可能會(huì)在剛 merge 一個(gè) PR 之后，立刻收到一個(gè) "Build failed" 的郵件。
這種郵件一般會(huì)發(fā)給負(fù)責(zé)人以及提交代碼的你，這種感覺很不好。尤其你作為一個(gè) Review 代碼的人，剛點(diǎn)擊 "Approve" 某個(gè) PR，然后此 PR 被 Merge 之后，收到一個(gè)這樣的郵件。我想下一次，再 Review 他的 PR 的時(shí)候，就會(huì)格外小心一點(diǎn)，小心的看看會(huì)不會(huì)出現(xiàn) Lint 不通過(guò)的情況。因?yàn)檫@樣會(huì)顯得像是我們做錯(cuò)了什么一樣，"我剛剛認(rèn)同了你，你就出錯(cuò)了"。
所以在提 PR 之前，在當(dāng)前你的 feature branch 上跑一遍 Lint 的腳本是特別重要的，如果你本機(jī)的 Lint 配置和 Jenkins 服務(wù)器一致的話，對(duì)于單個(gè)文件的修改，你也可以嘗試使用快鍵鍵 F2 來(lái)檢查單個(gè)文件中，可能的代碼隱患。
5. 盡早閱讀對(duì)方的意見并給予回復(fù)
一個(gè) PR 發(fā)布出去之后，其他工程師就可以在 PR 的頁(yè)面上提出自己的意見和建議。
我建議，盡早閱讀這些建議，并都給予回復(fù)。如果采納對(duì)方的建議，就直接按照思路修改代碼，并回復(fù)“已修改”。當(dāng)然有一些并非強(qiáng)制的建議，你也可以回復(fù)“謝謝建議，但是我覺得我這樣處理更好”，并附上理由。
雖然少部分公司會(huì)把 Code Review 納入績(jī)效當(dāng)中，來(lái)顯示對(duì) Code Review 的重視。但是通常并不會(huì)為工程師額外分配 Code Review 的時(shí)間，一般都是通過(guò)工作的間隙，來(lái)進(jìn)行 Code Review。
這就帶來(lái)了一個(gè)問(wèn)題，我此次的評(píng)論，兩天以后你給我回復(fù)，我還需要思考我當(dāng)時(shí)為什么會(huì)有這種想法，提了一個(gè)這個(gè)評(píng)論。線程的切換總是要消耗資源的。但是如果在我評(píng)論之后，作者立刻給予回復(fù)，我就不需要切換上下文就可以很連貫的對(duì)這次評(píng)論再進(jìn)行一次思考。
這也是一件可以讓人輕松 Review 的事情。
【本文為51CTO專欄作者“張旸”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過(guò)微信公眾號(hào)聯(lián)系作者獲取授權(quán)】
