如何建立良好的代碼審查Committer機制？

【引言】

大家好，我們華為公司上下正在致力于進行可信軟件開發的變革，其中重要的一環就是代碼審查制度的建立,?在本文中我們來討論一下代碼審查Committer的問題。

【干凈代碼】

一般來說，我們程序員，工程師，架構師等等跟代碼接觸比較密切的群體對于代碼都有很深的感情。我們希望我們的代碼既要干凈，復雜度又要盡可能的低，項目進展又快，以后維護起來也很輕松。

那么問題就來了，怎么才能保證代碼既干凈又簡單再入庫呢？相信參與過很多不同團隊開發的同事一定深有體會，在不同的團隊里面代碼審查的方式各不相同。接下來我們就探討一下行業內的現狀。下面的案例都是根據本人實際參與過的項目進行描述和分析，內容中略去具體公司名稱和技術細節。

【現狀1：會議討論模式?】

這種模式是指團隊中盡可能多的成員參與到代碼審查過程當中，以小組會議討論的形式逐行分步驟的審查代碼。

具體形式是大家共享一個電腦屏幕，對于新的更改進行討論，如果有不同意見就提出來研究有沒有更好的方案。如果沒有異議的話，就提交代碼，如果有問題，達成共識以后進行修改，修改完成以后再進行下一輪的討論。直到代碼入庫。

【會議討論模式優點】

這種模式的好處是有助于讓每個成員互相了解其他成員的技術細節，包括每個人在做什么。并且對于團隊成員之間相互了解和相互學習很有幫助。其中某個或某幾個人的離職不會導致項目出現很明顯的停滯。我們說如果整個項目的代碼量不是很龐大的情況下，這是一個非常好的辦法。很多大公司中很多團隊在使用這種模式。

【會議討論模式缺點】

現在說一下這種模式的缺點，它的最大缺點就是效率低。假如看一個代碼審查需要一人一個小時，五個人的話就是五個人小時。這種時間的開銷在很多公司是通過加班來實現的。長期使用的話會形成疲勞戰術，導致每個人都很疲勞，最后也會影響到代碼的質量。

【會議討論模式的改進方案】

那么如何保留這種模式的好處又規避其缺點呢？下面是我個人認為的一種改進方案。代碼提交者結合自己的代碼講解自己任務的內容，由項目組長或者代碼審查專員給出審查意見。絕大多數時間其他人就是旁聽，不過多討論。

這種改進方案的一個前提條件是代碼審查專員必須很了解整個項目的技術，包括里面的技術細節，只有這樣才會提出有價值的建議和給出準確的結論。具備這種能力的代碼審查專員必須具備很強的學習能力和深厚的行業經驗。

【現狀2：三人批準模式】

這種模式也是應用在大公司的團隊當中。基本思想就是，對一個代碼提交，只要你找到三個項目組成員給你批準信號就可以入庫。一般來說，代碼提交者會發出PR（Pull Request）的郵件給團隊成員。每個收到信的團隊成員都可以發出批準信號，提交者在收到三個批準信號以后，代碼入庫按鈕被激活，此時可以提交入庫。

【三人批準模式的優點】

相對而言節省了總的審查時間。不需要每個批準者預留時間做代碼審查，誰有空誰審查，審查人選比較自由，一般來說是能者多勞。

【三人批準模式的缺點】

困境一，如果代碼審查人員沒有看透代碼的情況下批準，容易造成低質量代碼入庫。這種情況存在于前端工程師批準后端工程師代碼，反之亦然。由于缺乏全局知識，這種情況放任下去就會造成很多冗余的代碼，冗余的代碼會增加項目的復雜度，從而能增加后續開發和維護的負擔。

困境二，如果審查人員觀點無法統一，沒有一個決斷者，會導致代碼遲遲無法入庫。

困境三，代碼風格不統一，代碼質量不易保障，增加了維護的難度。

困境四，在跨時區的團隊合作中要湊足三個代碼批準者可能存在無謂地等待。

【三人批準模式的改進】

要讓批準代碼修改的三人有共同的理念，及時溝通，協同作戰。這實際上要求動態的三個團隊成員整齊劃一，行動一致。在實踐中這樣的改進不太容易，常常流于形式。

再一個改進是改為一人批準模式。此人需要具備全棧的能力。從而可以縱觀全局，做出準確判斷。因此很強的學習能力是必不可少的。

【影響代碼審查的因素：?項目進度】

很多團隊在進行代碼審查的時候，常常以項目進度為理由進行妥協，從而讓自己不太滿意的代碼入庫，認為以后可以再做重構。

現實的情況是，如果你當初在代碼量不大的時候沒有對不滿意的代碼進行重構，在代碼量變大以后，你就更加沒有可能去做了。

【影響代碼審查的因素：?審查代碼人員能力】

代碼審查人員要從實際項目出發，有能力把握全局，給團隊成員予以指導，告訴成員們什么樣的代碼是合格的代碼。

代碼審查人員要有能力對代碼風格和標準做出決定，并且討論并說服團隊成員按照這個風格和標準執行。

具體的案例可能千差萬別，可以具體問題具體分析，一般的參考標準如下：

1.?????找一個通用的代碼格式化工具，大家一起用一套工具，提交之前對代碼進行格式化；

2.?????代碼的復雜度是不是控制在了最低程度？

3.?????命名方式要統一；

4.?????代碼即注釋；

5.?????在TODO區域中要使用注釋；

6.?????代碼提交工具和方式要統一，有UI界面工具的盡量避免使用命令行工具；

7.?????在主要代碼分支上，保持代碼歷史線性化，要避免代碼歷史交叉；

【一個假定案例的推演】

我們假定有一個項目，項目可大可小。要有項目Owner和項目的技術負責人。

項目Owner負責研究并提出業務需求；

項目的技術負責人要：

---?研究技術選型；

---?研究業務邏輯；

---?搭好前后端的基礎架構代碼;

---?至少要走通一個前后端協同工作的業務邏輯；

--- 代碼審查

項目成員要按照已有的業務邏輯，在保持復雜度平行增加的情況下，添加更多的業務邏輯，技術負責人負責代碼審查。

至此，一個項目就有了良好的開端。

當項目業務邏輯增加涉及到基礎架構代碼變動的時候，要考慮是否要把要增加的這部分業務邏輯獨立出來作為一個工程或者服務。

獨立的工程是指工具處理類相關，測試類相關,數據庫管理相關等等。

獨立的服務是指：

1.?????前端頁面相關，比如一套獨立的管理系統。

2.?????后端服務，比如對應獨立前端的API系統。

3.?????后端服務，消息通知系統，無任何前端待用的獨立子系統。

【小結】

好了，本文中對于代碼審查Committer機制做了拋磚引玉式的探索，從行業現狀到改進方法和案例推演等各方面做了簡要地闡述。希望對大家有所裨益。歡迎留言，討論，批評，指正。

軟件開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。