這篇文章主要講解了“怎么做一個(gè)完美的Pull Request”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“怎么做一個(gè)完美的Pull Request”吧！

創(chuàng)新互聯(lián)堅(jiān)信：善待客戶(hù)，將會(huì)成為終身客戶(hù)。我們能堅(jiān)持多年，是因?yàn)槲覀円恢笨芍档眯刨?lài)。我們從不忽悠初訪客戶(hù)，我們用心做好本職工作，不忘初心，方得始終。十多年網(wǎng)站建設(shè)經(jīng)驗(yàn)創(chuàng)新互聯(lián)是成都老牌網(wǎng)站營(yíng)銷(xiāo)服務(wù)商,為您提供成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、H5高端網(wǎng)站建設(shè)、網(wǎng)站制作、品牌網(wǎng)站建設(shè)、微信小程序服務(wù),給眾多知名企業(yè)提供過(guò)好品質(zhì)的建站服務(wù)。

1.添加關(guān)于“為什么”的代碼注釋

在寫(xiě)一個(gè)新功能的時(shí)候，會(huì)有很多與之相關(guān)的信息。寫(xiě)代碼時(shí)要全盤(pán)考慮需求，第三方系統(tǒng)的局限性，以及和遺留代碼庫(kù)的交互。但是別人不了解其上下文來(lái)源，所以看到這個(gè)代碼時(shí)會(huì)問(wèn)“它為什么在這?”或是“為什么要選擇這種方法?”因此要通過(guò)添加解釋性的注釋?zhuān)岄喿x代碼的人提前知曉“為什么”。筆者不認(rèn)同一些人宣揚(yáng)的觀點(diǎn)：注釋有害，應(yīng)當(dāng)忽略。

注釋有很多種類(lèi)。那些描述代碼用途的確實(shí)是累贅。提取一個(gè)方法，采用一個(gè)精心挑選的命名，就能消除這種麻煩。另一方面，當(dāng)解釋為什么這樣寫(xiě)代碼時(shí)，也增加了代碼閱讀者的信息量。這些注釋將閱讀者的認(rèn)知水平理想化地提高到了與編碼人員相同的層級(jí)，這有助于增進(jìn)對(duì)代碼的理解。

筆者的注釋通常會(huì)給出類(lèi)存在的原因、相關(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)簽的鏈接。

• 對(duì)已完成事件的總結(jié)(如果不能從pullrequest的標(biāo)題中看出)。

• 相關(guān)pull request的鏈接(例如在另一服務(wù)中的相關(guān)變化)。

不要把自認(rèn)為理解代碼需要的信息放在對(duì)pullrequest的描述里，應(yīng)當(dāng)進(jìn)行代碼注釋?zhuān)核鼈兊男Ч语@著，有助于未來(lái)代碼閱讀者的閱讀。

3.精簡(jiǎn)pull request

這是一項(xiàng)強(qiáng)大的技術(shù)，谷歌甚至就小型pullrequest的益處單獨(dú)寫(xiě)了一篇文章(https://google.github.io/eng-practices/review/developer/small-cls.html)。以下是筆者最喜歡的小型pull  request的特點(diǎn)：

• 審查更徹底

• 審查更快捷

• 更易合并(頻繁的合并能減少?zèng)_突)

• 如果被拒絕，浪費(fèi)的精力更少

以下辦法能使小型pull request的編寫(xiě)更簡(jiǎn)單：

• 將重構(gòu)提取到單獨(dú)的pull request中

• 將大型功能分解(即使它們不是面向用戶(hù)的)

• 學(xué)一些git小竅門(mén)很有幫助，把git add --patch和git rebase --interactive當(dāng)成朋友

• 把長(zhǎng)期運(yùn)行的功能分支設(shè)置為pull request的目標(biāo)，而非master的目標(biāo)： 

4.快速回應(yīng)審查

處理審查注釋通常比較費(fèi)時(shí)，需要修復(fù)打字錯(cuò)誤、添加遺漏的測(cè)試案例、對(duì)方法重命名等。如果你能快速完成，你的同伴就能花更少的時(shí)間來(lái)記憶與pull  request相關(guān)的信息。

但這種方法的缺點(diǎn)是會(huì)增加上下文切換的工作量，替代方法是使用番茄工作法(Pomodoro  technique)：每工作25分鐘穿插一次短暫的休息。它能讓人更專(zhuān)注、更有成效、更健康，并減輕疲勞度，休息后的上下文切換也會(huì)進(jìn)行得更加自然。負(fù)面的破壞性影響雖然沒(méi)有消失，但是會(huì)大大降低。

5.給自己的pull request注釋

為某些變化(例如刪除和重構(gòu))添加解釋性的代碼注釋是沒(méi)有意義的，應(yīng)當(dāng)考慮為自己的pull request注釋?zhuān)o審查者提供更多的上下文。

6.在創(chuàng)建pull request前重定新master的基準(zhǔn)

這樣做有很多好處：

• 測(cè)試可能在本地分支中會(huì)通過(guò)，但在應(yīng)用的最近更新時(shí)會(huì)失敗。

• 能夠使用最新添加的功能(例如新的工具類(lèi))。

• 審查者如果沒(méi)能找到近期的變化，就會(huì)感到困惑。

相比合并，筆者更喜歡重定基底，因?yàn)橹囟ɑ资沟梅种H包含相關(guān)的提交。

7.不要修改經(jīng)過(guò)審查的提交——要發(fā)送新的

要在單獨(dú)的提交中處理審查注釋?zhuān)皇切薷幕蛘叱ジ?。這樣能夠讓審查者更容易核對(duì)在上次審查后發(fā)生的變化：

8.在實(shí)現(xiàn)功能之前討論整體方法

這可以省下很多時(shí)間。在要處理更復(fù)雜的重構(gòu)和功能之前，先與同事討論一下方法。與其他的開(kāi)發(fā)人員討論，解釋這項(xiàng)任務(wù)和你的想法，他們也許會(huì)表示贊成，也許會(huì)提出更好的方法。

很多時(shí)候筆者都面臨著初步協(xié)調(diào)的缺失，好幾天的工作成果白白浪費(fèi)。想象一下你連續(xù)五天做一件事情，結(jié)果卻聽(tīng)到“對(duì)不起，其實(shí)我們不需要……”想要把自己從失望中拯救出來(lái)，你得盡早獲得反饋。

感謝各位的閱讀，以上就是“怎么做一個(gè)完美的Pull Request”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)怎么做一個(gè)完美的Pull Request這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！