怎么做一個完美的PullRequest

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

創(chuàng)新互聯(lián)堅信：善待客戶，將會成為終身客戶。我們能堅持多年，是因為我們一直可值得信賴。我們從不忽悠初訪客戶，我們用心做好本職工作，不忘初心，方得始終。十多年網(wǎng)站建設經(jīng)驗創(chuàng)新互聯(lián)是成都老牌網(wǎng)站營銷服務商,為您提供成都網(wǎng)站設計、成都網(wǎng)站建設、網(wǎng)站設計、H5高端網(wǎng)站建設、網(wǎng)站制作、品牌網(wǎng)站建設、微信小程序服務,給眾多知名企業(yè)提供過好品質(zhì)的建站服務。

1.添加關于“為什么”的代碼注釋

在寫一個新功能的時候，會有很多與之相關的信息。寫代碼時要全盤考慮需求，第三方系統(tǒng)的局限性，以及和遺留代碼庫的交互。但是別人不了解其上下文來源，所以看到這個代碼時會問“它為什么在這?”或是“為什么要選擇這種方法?”因此要通過添加解釋性的注釋，讓閱讀代碼的人提前知曉“為什么”。筆者不認同一些人宣揚的觀點：注釋有害，應當忽略。

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

筆者的注釋通常會給出類存在的原因、相關資源的鏈接以及代碼的前因后果：

# 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.描述清晰

有關pull request的描述為審查者提供任務最初的上下文，包括：

• 標簽的鏈接。

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

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

不要把自認為理解代碼需要的信息放在對pullrequest的描述里，應當進行代碼注釋：它們的效果更加顯著，有助于未來代碼閱讀者的閱讀。

3.精簡pull request

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

• 審查更徹底

• 審查更快捷

• 更易合并(頻繁的合并能減少沖突)

• 如果被拒絕，浪費的精力更少

以下辦法能使小型pull request的編寫更簡單：

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

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

• 學一些git小竅門很有幫助，把git add --patch和git rebase --interactive當成朋友

• 把長期運行的功能分支設置為pull request的目標，而非master的目標： 

4.快速回應審查

處理審查注釋通常比較費時，需要修復打字錯誤、添加遺漏的測試案例、對方法重命名等。如果你能快速完成，你的同伴就能花更少的時間來記憶與pull  request相關的信息。

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

5.給自己的pull request注釋

為某些變化(例如刪除和重構(gòu))添加解釋性的代碼注釋是沒有意義的，應當考慮為自己的pull request注釋，給審查者提供更多的上下文。

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

這樣做有很多好處：

• 測試可能在本地分支中會通過，但在應用的最近更新時會失敗。

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

• 審查者如果沒能找到近期的變化，就會感到困惑。

相比合并，筆者更喜歡重定基底，因為重定基底使得分支僅包含相關的提交。

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

要在單獨的提交中處理審查注釋，而不是修改或者除去更改。這樣能夠讓審查者更容易核對在上次審查后發(fā)生的變化：

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

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

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

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

文章標題：怎么做一個完美的PullRequest
當前鏈接：http://muchs.cn/article34/jchipe.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供搜索引擎優(yōu)化、建站公司、響應式網(wǎng)站、品牌網(wǎng)站建設、虛擬主機、手機網(wǎng)站建設

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)