(轉(zhuǎn)載請(qǐng)注明出自 http://m.shnenglu.com/converse 那誰)

一直以來想找機(jī)會(huì)談?wù)勀壳斑@個(gè)項(xiàng)目組內(nèi)采用的代碼提交制度,今天整理一下.

分如下幾個(gè)流程:
1) 在trac系統(tǒng)上建立ticket,寫好這個(gè)任務(wù)的目的,并且accept這個(gè)ticket.
2) 修改代碼,把相關(guān)的修改過的代碼(一般還應(yīng)包括相關(guān)的測(cè)試用例的代碼,后面會(huì)加以說明)提交到review board上.
3) 在review board上填寫如下幾個(gè)必要的信息:
a)第1)步建立的ticket的號(hào)碼(可以有好幾個(gè),也就是一次修改可以針對(duì)好幾個(gè)任務(wù)),以明確這次提交針對(duì)的是哪個(gè)任務(wù);
b)寫下測(cè)試了哪幾個(gè)測(cè)試用例,對(duì)這次的提交寫一段描述.
c)寫下給哪些人做review.reviewer的角色分為兩種,一種是負(fù)責(zé)人,另一種就是普通的組員.每一次提交,必須保證reviewer中有至少一個(gè)負(fù)責(zé)人,并且需要所有的reviewer都通過了這次修改,才能向代碼庫提交代碼.reviewer會(huì)針對(duì)提交的代碼進(jìn)行批注回復(fù).
4)一般情況下,代碼不會(huì)在第一次提交就能通過review,大多數(shù)情況會(huì)被打回修改,于是2)-4)三個(gè)步驟將循環(huán)進(jìn)行下去直到代碼通過review為止.
5) 提交了代碼之后,1)中建立的ticket會(huì)被自動(dòng)關(guān)閉,并且將在ticket的回復(fù)自動(dòng)寫上本次提交修改的文件以及svn revision號(hào),這樣以后再看起來就知道是哪次提交并且修改了哪些文件針對(duì)的又是哪個(gè)功能了.
6) 有一臺(tái)服務(wù)器專門作為buildbot機(jī)器, 這臺(tái)機(jī)器在每次提交了代碼之后, 將自動(dòng)清空原來的代碼目錄,更新最新的代碼,重新編譯,然后把里面的測(cè)試用例全部跑一遍.我們的項(xiàng)目使用的tcmalloc,會(huì)檢查內(nèi)存泄漏,所以在測(cè)試用例測(cè)試失敗,以及有內(nèi)存泄漏的時(shí)候,buildbot都會(huì)失敗.需要補(bǔ)充一點(diǎn)的是,除了每次提交代碼會(huì)導(dǎo)致buildbot重新編譯新的代碼,在每晚的一個(gè)固定時(shí)間,即使沒有更新代碼,也會(huì)做相同的動(dòng)作.buildbot的存在,就是為了不斷的清空編譯文件重新編譯再跑測(cè)試用例,以大量的測(cè)試消除隨機(jī)性保證正確性.

以上是整個(gè)代碼提交機(jī)制的大體流程說明,下面談里面的細(xì)節(jié).

1)上面的第1)步中,建立trac的ticket時(shí),需要指定一個(gè)milestone,一般我們對(duì)必須做的事情是每周以日期命名建立一個(gè)milestone,這樣,你做的任務(wù)就會(huì)自然的變成每周可以去跟進(jìn)的任務(wù).
2)第2)步中,寫測(cè)試用例針對(duì)的是每個(gè)類或者每個(gè)頭文件對(duì)外暴露的API接口,比如對(duì)外的API c使用內(nèi)部的函數(shù)B,那么是沒有辦法對(duì)函數(shù)B編寫測(cè)試用例的.我們的要求是, 任何的一個(gè)新增的API都需要寫針對(duì)它進(jìn)行測(cè)試的測(cè)試用例,不一定只有一個(gè),因?yàn)樾枰紤]的情況可能很多,總而言之,盡可能的考慮齊全.假如本次修改修改了內(nèi)部函數(shù)B,那么依賴于函數(shù)B的API c它的測(cè)試用例也就需要再測(cè)試了.這些測(cè)試用的代碼也會(huì)一并提交到代碼庫中,因?yàn)檫@樣才能保證buildbot更新之后也按照最新的測(cè)試用例進(jìn)行測(cè)試.
3) 代碼提交到reviewboard之前,還需要過lint這一關(guān),對(duì)基本的代碼風(fēng)格進(jìn)行檢查.我們使用的是google c++ code style.
4) reviewer中的負(fù)責(zé)人角色很重要, 起著看門人的作用,任何的一次修改提交,都必須至少經(jīng)過一個(gè)負(fù)責(zé)人的review, 所以對(duì)他的要求就相對(duì)高些了,除了要完成自己的工作外,還需要認(rèn)真review他人的代碼,而要review他人的代碼并且給出好的意見來,又要求他本人除了編碼能力外,還要在業(yè)務(wù)層面對(duì)別人的工作有大體的了解,不然沒法review了.
5) 從前文可以看出,review實(shí)在是一個(gè)繁雜的工作,很有可能在review階段被打回修改代碼,就我的經(jīng)驗(yàn)而言,提交review的人要將提交的任務(wù)盡量的劃分的細(xì)一些就來的很重要了.在提交review的時(shí)候,我一直堅(jiān)持DOTDIW原則(Do One Thing,Do It Well).相反的例子,我們組有個(gè)同事,做了一個(gè)很大的功能,光是完成這個(gè)大的功能,就花費(fèi)好幾周的時(shí)間,提交review的時(shí)候代碼量大,有個(gè)幾千行的,這樣別人review起來也慢,而且一旦不通過需要修改,又是一個(gè)苦力活兒.這樣一折騰,一個(gè)月時(shí)間過去了.如果當(dāng)時(shí)能對(duì)整體的功能有個(gè)把握,懂得劃分模塊層次,逐個(gè)提交,也許會(huì)好些.當(dāng)然,大規(guī)模的代碼提交有時(shí)并不能完全的避免,比如一個(gè)比較大的重構(gòu),牽一發(fā)而動(dòng)全身的,我只是說如果可能,應(yīng)盡量避免大規(guī)模代碼的提交,并且最重要的是:每次提交最好僅針對(duì)一個(gè)功能點(diǎn).

以上是對(duì)流程從整體到細(xì)節(jié)的描述.現(xiàn)在談?wù)勎业目捶?
先來談優(yōu)點(diǎn):
1) 通過codereview制度,保證了項(xiàng)目組成員之間能夠在代碼層面上直接的進(jìn)行交流.我想這一點(diǎn)是最重要的,沒有之一.
如果你是一個(gè)水平差一些的程序員,那么有比你牛叉的人幫你review,相當(dāng)于是讀書的時(shí)候有老師幫你閱卷修改作業(yè),可以指正你的問題所在.我在被人review的過程中就聽到了別人對(duì)我很多的意見.而如果是一個(gè)水平較高的人,是不是對(duì)水平差的人進(jìn)行codereview就是浪費(fèi)他的時(shí)間了呢?我個(gè)人認(rèn)為,這個(gè)事情分怎么看.從團(tuán)隊(duì)的角度看,按照木桶理論,最短的短板往往決定了能達(dá)到的水平.總不能指望所有的事情都由老鳥完成,所以老人在幫新人review代碼的時(shí)候間接的幫助了新人的成長(zhǎng),同時(shí)作為項(xiàng)目組中資歷比較深的人,也應(yīng)該對(duì)項(xiàng)目多費(fèi)一些時(shí)間進(jìn)行把關(guān).我覺得這一點(diǎn)無可厚非.同時(shí),即使是新人,通過閱讀他人的代碼并且交流,也可以學(xué)習(xí)到別人的思想.
codereview制度從上面的角度上保證了項(xiàng)目成員可以直接通過代碼進(jìn)行交流,簡(jiǎn)單的說,誰寫的代碼質(zhì)量如何,一到了review,一目了然.寫的好的通過的快,寫的不好被打回修改多了自己也會(huì)長(zhǎng)記性,還可以多看別人的代碼進(jìn)行學(xué)習(xí).這樣,在一定層面上可以使項(xiàng)目組成員的能力盡可能的接近.我能力長(zhǎng)了一級(jí),相應(yīng)的也會(huì)拉動(dòng)項(xiàng)目組中的人升級(jí).

2) 測(cè)試用例.我之前提到的測(cè)試驅(qū)動(dòng)開發(fā),想法就來自于項(xiàng)目組中編寫測(cè)試用例+buildbot執(zhí)行測(cè)試用例的做法.如何證明一個(gè)API是確定無誤的?我覺得這個(gè)問題似乎非常難.除了一些可以通過數(shù)學(xué)上邏輯上證明的情況外,還需要考慮很多其他的隨機(jī)情況.比如線程的切換是隨機(jī)的,某個(gè)文件夾恰好存在是隨機(jī)的,等等.這些隨機(jī)出現(xiàn)的問題,很多時(shí)候不能在某一次測(cè)試中顯現(xiàn)出來.但是如果有了buildbot,不停的更新,編譯,執(zhí)行,總會(huì)有暴露問題的一天.另外,之前我也提到過,腦中如果有了測(cè)試用例的概念存在,每寫一個(gè)API時(shí)都會(huì)考慮到針對(duì)它的用例應(yīng)該是怎樣的,從另一個(gè)角度,也幫助你的設(shè)計(jì)--你需要考慮這個(gè)API的輸入,輸出,異常情況都有哪些,如何測(cè)試到.測(cè)試用例的存在,保證項(xiàng)目盡量的做到了"可控制".

缺點(diǎn):
1) 從上面的流程可以看出,走完一個(gè)代碼提交的流程需要花費(fèi)大量的精力/時(shí)間(有一些還是他人的精力/時(shí)間),所以,也許這個(gè)制度并不適合于那種時(shí)間壓力比較大的項(xiàng)目.

2) 有幾個(gè)地方很難堅(jiān)持,比如codereview時(shí),有些reviewer會(huì)走過場(chǎng),也沒怎么看代碼就直接通過了,這樣就會(huì)流于形式了.還有編寫測(cè)試用例,也是一件很耗時(shí)間的事情.

3) 由于codereview制度的存在,給review中的負(fù)責(zé)人帶去的壓力很大,因?yàn)楸旧硭凶约旱墓ぷ?又要盡量對(duì)他人的業(yè)務(wù)/代碼進(jìn)行了解,就像那種負(fù)載很大的服務(wù)器一樣,有時(shí)候會(huì)不堪重負(fù).這一點(diǎn)上,我的想法是,項(xiàng)目組內(nèi)的其他成員,如果能積極主動(dòng)一些,多花時(shí)間了解別人的代碼,盡量分擔(dān)review的任務(wù),或者試著成長(zhǎng)為負(fù)責(zé)人級(jí)別(降低單點(diǎn)故障率:),也許是一個(gè)好辦法.不過,這還得看人了.

整個(gè)代碼提交流程上的軟件,目前我所知的都是使用的開源軟件:SVN, google c++ code style lint,review board,buildbot,trac,測(cè)試用例的編寫上使用的是google的測(cè)試用例框架gtest.不過,整合起這些軟件搭建好這個(gè)流程就不是那么容易了,用了一人/半年左右的時(shí)間,才讓這個(gè)流程基本穩(wěn)定下來.

總之,這套機(jī)制中,既有人為的干涉,也有機(jī)器層面上的干涉,也許并不是最完美的,但是盡了最大的力量去保證項(xiàng)目的正確性和可控性.

以正確的方式正確的制度做事,是將事情做好的一個(gè)關(guān)鍵.