在目前已使用的質量內建的工程實踐中不可否認的一個實踐為代碼審查 它被用作提高產品交付質量和提高開發(fā)過程效率的有效措施妈踊。 Git又是目前當紅的源碼管理工具穴墅，若你的團隊目前已經選用了GitLab來作為托管工具，那此文中你可以學到如何通過GitLab的Merge Request（合并請求）進行代碼審查以及我們遵循的現有代碼審查最佳實踐來改進工作流程。
在我們討論如何進行代碼審查之前姑食，讓我們先來回顧一下代碼評審的一般原則纱耻。
代碼評審的一般原則
- 代碼評審是任何開發(fā)過程中不可或缺的一部分 - 將其打印出來并放在墻上以便記住芭梯。可參考之前寫過的你的代碼評審需要來一次清單革命弄喘！
- 代碼評審是在小段的邏輯完整的代碼片段上執(zhí)行的玖喘，例如功能，任務蘑志，錯誤修復累奈，改進等。
- 只有通過審核的代碼才會發(fā)送到測試部門急但。
- 該項目的所有開發(fā)人員都會進行代碼評審澎媒，無論他們的級別如何。
- 項目的所有開發(fā)人員都應該通過代碼評審波桩，無論他們的級別如何（初級開發(fā)人員也應該審查經驗豐富的中高級專家的代碼）戒努。
接下來我們將介紹如何使用GitLab提供的工具來進行代碼評審。
GitLab中的merge request指的是把代碼從一個分支合并到另一個分支上做的操作镐躲。
創(chuàng)建一個Merge request會涉及到的主要參數為：
- source branch
- target branch
- title
- description
-
assignee
content_Creating-merge-request.png
使用Merge Request時的操作步驟：
- 編寫代碼并將其推送到單獨的分支储玫。
- 為主要開發(fā)分支創(chuàng)建合并請求。 Assignee以及說明字段和評論中被提到的那些人將通過電子郵件通知合并請求萤皂。如果需要某一位開發(fā)人員關注撒穷，你可以在描述字段中@該名開發(fā)人員。
- 等到MR被接受或拒絕裆熙，并提供有關必要修復的評論端礼。
- 參與有關修復的討論。 （GitLab允許回復評論）
- 修復弛车。
- 將更改推送到你的分支齐媒。
- 打開一個新合并如果最后一個MR被關閉（如果合并請求未關閉蒲每，它將自動更新纷跛，直到最后一次提交為止）。
- 通過注釋合并請求或以其他方式報告已實施的修復邀杏。
content_reviewing-merge-requests.png
應該將Merge Request分配給誰
對于合并請求贫奠，它們的分配取決于各種因素。根據項目的人數和專業(yè)水平望蜡，可以有不同的選擇唤崭。因此，如果您是團隊中唯一的開發(fā)人員脖律，請為自己分配合并請求谢肾。
否則，請與另一位在項目中獨立的開發(fā)人員交談小泉，并讓他審查彼此的代碼芦疏。文檔審查通常也是必要的冕杠，因為在您執(zhí)行此操作后，您將確保其他開發(fā)人員可以在必要時使用您的代碼酸茴。
如果您是項目的兩名開發(fā)人員分预，請相互分配合并請求。如果有三個或更多開發(fā)人員薪捍，您可以自由選擇笼痹。
你的團隊可以在工作日的開始和結束時或根據要求隨時進行代碼審查。團隊可以決定何時進行代碼審查酪穿，最重要的是團隊成員之間的持續(xù)協作凳干。
用Merge Requests產生的代碼評審如何進行更精細化的流程管理之后可以繼續(xù)討論。
