只有完美代碼不夠的，如何做一個完美的Pull Request？
想要提高團(tuán)隊(duì)績效，找到瓶頸是第一步?，F(xiàn)實(shí)中，最大的限制因素不是編碼速度，而是代碼審查。因此，為了加快審查速度，筆者對比了兩種pull request：
- 注釋很少并且快速合并的pullrequest
- 有很多注釋，需要多輪審查的pull request
我的結(jié)論是，有九種方式能讓審查pullrequest更輕松。
1.添加關(guān)于“為什么”的代碼注釋
在寫一個新功能的時候，會有很多與之相關(guān)的信息。寫代碼時要全盤考慮需求，第三方系統(tǒng)的局限性，以及和遺留代碼庫的交互。但是別人不了解其上下文來源，所以看到這個代碼時會問“它為什么在這?”或是“為什么要選擇這種方法?”
因此要通過添加解釋性的注釋，讓閱讀代碼的人提前知曉“為什么”。筆者不認(rèn)同一些人宣揚(yáng)的觀點(diǎn)：注釋有害，應(yīng)當(dāng)忽略。
注釋有很多種類。那些描述代碼用途的確實(shí)是累贅。提取一個方法，采用一個精心挑選的命名，就能消除這種麻煩。另一方面，當(dāng)解釋為什么這樣寫代碼時，也增加了代碼閱讀者的信息量。這些注釋將閱讀者的認(rèn)知水平理想化地提高到了與編碼人員相同的層級，這有助于增進(jìn)對代碼的理解。
筆者的注釋通常會給出類存在的原因、相關(guān)資源的鏈接以及代碼的前因后果：
- # First Crew Dragon launch was postponeddue to bad weather,
- # and now we needan event for the "second" first launch.
- # Hence the stupidname.
- classSecondFirstCrewDragonLaunch
- ...
- End
2.描述清晰
有關(guān)pull request的描述為審查者提供任務(wù)最初的上下文，包括：
- 標(biāo)簽的鏈接。
- 對已完成事件的總結(jié)(如果不能從pullrequest的標(biāo)題中看出)。
- 相關(guān)pull request的鏈接(例如在另一服務(wù)中的相關(guān)變化)。
不要把自認(rèn)為理解代碼需要的信息放在對pullrequest的描述里，應(yīng)當(dāng)進(jìn)行代碼注釋：它們的效果更加顯著，有助于未來代碼閱讀者的閱讀。
3.精簡pull request
這是一項(xiàng)強(qiáng)大的技術(shù)，谷歌甚至就小型pullrequest的益處單獨(dú)寫了一篇文章(https://google.github.io/eng-practices/review/developer/small-cls.html)。以下是筆者最喜歡的小型pull request的特點(diǎn)：
- 審查更徹底
- 審查更快捷
- 更易合并(頻繁的合并能減少沖突)
- 如果被拒絕，浪費(fèi)的精力更少
以下辦法能使小型pull request的編寫更簡單：
- 將重構(gòu)提取到單獨(dú)的pull request中
- 將大型功能分解(即使它們不是面向用戶的)
- 學(xué)一些git小竅門很有幫助，把git add --patch和git rebase --interactive當(dāng)成朋友
- 把長期運(yùn)行的功能分支設(shè)置為pull request的目標(biāo)，而非master的目標(biāo)：
4.快速回應(yīng)審查
處理審查注釋通常比較費(fèi)時，需要修復(fù)打字錯誤、添加遺漏的測試案例、對方法重命名等。如果你能快速完成，你的同伴就能花更少的時間來記憶與pull request相關(guān)的信息。
但這種方法的缺點(diǎn)是會增加上下文切換的工作量，替代方法是使用番茄工作法(Pomodoro technique)：每工作25分鐘穿插一次短暫的休息。它能讓人更專注、更有成效、更健康，并減輕疲勞度，休息后的上下文切換也會進(jìn)行得更加自然。負(fù)面的破壞性影響雖然沒有消失，但是會大大降低。
5.給自己的pull request注釋
為某些變化(例如刪除和重構(gòu))添加解釋性的代碼注釋是沒有意義的，應(yīng)當(dāng)考慮為自己的pull request注釋，給審查者提供更多的上下文。
6.在創(chuàng)建pull request前重定新master的基準(zhǔn)
這樣做有很多好處：
- 測試可能在本地分支中會通過，但在應(yīng)用的最近更新時會失敗。
- 能夠使用最新添加的功能(例如新的工具類)。
- 審查者如果沒能找到近期的變化，就會感到困惑。
相比合并，筆者更喜歡重定基底，因?yàn)橹囟ɑ资沟梅种H包含相關(guān)的提交。
7.不要修改經(jīng)過審查的提交——要發(fā)送新的
要在單獨(dú)的提交中處理審查注釋，而不是修改或者除去更改。這樣能夠讓審查者更容易核對在上次審查后發(fā)生的變化：
8.在實(shí)現(xiàn)功能之前討論整體方法
這可以省下很多時間。在要處理更復(fù)雜的重構(gòu)和功能之前，先與同事討論一下方法。與其他的開發(fā)人員討論，解釋這項(xiàng)任務(wù)和你的想法，他們也許會表示贊成，也許會提出更好的方法。
很多時候筆者都面臨著初步協(xié)調(diào)的缺失，好幾天的工作成果白白浪費(fèi)。想象一下你連續(xù)五天做一件事情，結(jié)果卻聽到“對不起，其實(shí)我們不需要……”想要把自己從失望中拯救出來，你得盡早獲得反饋。
9.感謝審查者的建議
深刻地理解別人做出的改變并且提出有用的建議需要付出很多努力——請對于這一事實(shí)表達(dá)認(rèn)同和感激。記住，代碼的變化是短暫的——與隊(duì)友的關(guān)系卻是永恒的。
減少在代碼審查上花費(fèi)的時間，團(tuán)隊(duì)表現(xiàn)會很快得到優(yōu)化，在下一次的pull request中運(yùn)用這些小竅門，結(jié)果會大有不同。
