九色国产,午夜在线视频,新黄色网址,九九色综合,天天做夜夜做久久做狠狠,天天躁夜夜躁狠狠躁2021a,久久不卡一区二区三区

Pull Request是Bitbucket、GitHub等源代碼托管系統(tǒng)為了方便開發(fā)者之間協(xié)作而提供的一個(gè)功能，它提供了一個(gè)用戶友好的Web界面來幫助審查人員進(jìn)行代碼審查。開發(fā)人員可以通過GitHub發(fā)出Pull Requests要求請(qǐng)求他人將程序拉下來進(jìn)行代碼審查。一個(gè)好的Pull Request不僅僅只是代碼的事情，還牽涉到代碼審查者對(duì)代碼的審查，所以開發(fā)者不僅要寫出好的代碼，還必須迎合審查者的審查工作，才能給使得自己貢獻(xiàn)的代碼順利通過審查并合并到master分支?，F(xiàn)對(duì)丹麥的程序員、軟件架構(gòu)師、獨(dú)立顧問Mark Seemann在自己博客中發(fā)布的一篇題為《關(guān)于Pull Request的十個(gè)建議》的文章進(jìn)行一個(gè)全面的整理，以供讀者閱讀和參考。具體內(nèi)容如下：

1. 進(jìn)行較小的Pull Request

一個(gè)小且集中的Pull Request會(huì)使得提交的代碼更加容易通過審核。據(jù)Mark Seemann根據(jù)自己的經(jīng)驗(yàn)透漏，對(duì)提交代碼進(jìn)行審查所花費(fèi)的時(shí)間是隨著代碼大小呈指數(shù)增長，而非線性增長；Pull Request多大才合適與Pull Request做了什么相關(guān)，最好少于12個(gè)文件的改變。如果Pull Request非常大，審查者就需要安排連續(xù)、相對(duì)比較長的時(shí)間進(jìn)行審查，就會(huì)造成審查過程的延遲。

2. 每個(gè)Pull Request只做一件事

就如軟件設(shè)計(jì)模式中的單一責(zé)任原則所指：一個(gè)類只負(fù)責(zé)一個(gè)功能領(lǐng)域中的相應(yīng)職責(zé)，因此一個(gè)Pull Request也應(yīng)只關(guān)注一件事情。如果一次Pull Request做了多件事情的話，將會(huì)增加審查過程的延遲、審查被拒絕的可能性。

3. 注意代碼行的字?jǐn)?shù),最好少于80個(gè)字

代碼審查者會(huì)使用不同的審查工具來審查提交的代碼，并且GitHub和Stash還提供了不同形式的視圖，這樣就使得代碼審查者能通過不同視圖非常方便來審查用戶的提交。如果代碼行比較寬的話，審查者就不能在一個(gè)屏幕或者半個(gè)屏幕中來閱讀代碼，不得不拖動(dòng)滾動(dòng)條來閱讀代碼。為了使得代碼比較容易審查，每行代碼最好少于80個(gè)字符。

4. 避免重新格式化代碼

就算自己覺得應(yīng)該改變當(dāng)前代碼的格式以適合自己的風(fēng)格，但是請(qǐng)不要這么做。在源代碼上，用戶對(duì)每個(gè)字節(jié)的改變將會(huì)在不同的審查視圖顯示出來。有些審查者會(huì)選擇忽略空格改變，但是有些審查者會(huì)審查這些代碼，對(duì)這些格式化引起的代碼審查屬于不必要的審查。如果真需要解決空格問題的話，就需要在其他文件里移動(dòng)代碼、改變格式或者對(duì)代碼做其他樣式改變，并在Pull Request注釋中給出相應(yīng)的說明。

5. 確保代碼能夠編譯通過

在提交Pull Request時(shí)，應(yīng)該首先在自己的電腦上進(jìn)行編譯構(gòu)建。在編譯構(gòu)建過程中，務(wù)必注意編譯過程出現(xiàn)的警告，要把警告當(dāng)作錯(cuò)誤來對(duì)待，這些警告可能不會(huì)阻止編譯，就有可能被忽略。然而，當(dāng)用戶Pull Request操作引起了很多編譯警告的話，代碼審查者就有可能拒絕對(duì)應(yīng)的提交。

6. 確保提交的代碼能夠通過所有測試

即使問題代碼已經(jīng)做了自動(dòng)化測試，但是在提交Pull Request時(shí)，也要?jiǎng)?wù)必保證針對(duì)代碼的所有測試都必須通過。

7. 添加測試

為代碼建立測試規(guī)則，即使出現(xiàn)問題的代碼已經(jīng)做過了自動(dòng)化測試，最好也要為自己提交的代碼也做下測試。

8.記錄下自己提交的原因

利用文檔對(duì)代碼進(jìn)行注釋、對(duì)自己的代碼直接進(jìn)行注釋、利用版本控制器提供的提交信息功能備注信息、利用Pull Request 管理系統(tǒng)（如GItHub或者Stash）添加自定義的Pull Request注釋信息。

9. 編寫符合編碼規(guī)范的代碼

按照代碼正確性規(guī)則編寫代碼，并附上有效的代碼注釋、提交信息、Pull Request信息等。

10. 避免顛簸

不同審查者對(duì)Pull Request有可能具有不同的觀點(diǎn)，這就會(huì)導(dǎo)致顛簸的情況，就需要用戶移除沖突的提交和推送修改的分支，并備注有效的信息。

感謝郭蕾對(duì)本文的審校。

給InfoQ中文站投稿或者參與內(nèi)容翻譯工作，請(qǐng)郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ）或者騰訊微博（@InfoQ）關(guān)注我們，并與我們的編輯和其他讀者朋友交流。