來源：范鋼的博客

也許你是一位項目經(jīng)理，也許你是一位項目骨干成員,，或者開發(fā)小組長,。在我發(fā)表“如何提高代碼質(zhì)量”的這一系統(tǒng)文章后，有許多網(wǎng)友都向我抱怨,，說他無法把握整個項目組成員的代碼質(zhì)量,。我想,，這也是所有項目組普遍存在的問題吧，它通常表現(xiàn)為以下幾個問題：

軟件項目普遍存在的問題

1）新手,。任何項目組成員都不可避免地出現(xiàn)新手,，他們往往是剛剛從大學(xué)畢業(yè)的學(xué)生。這些新手由于軟件開發(fā)時間太短,，往往技術(shù)不成熟,，沒有形成良好的開發(fā)習(xí)慣，所以編寫代碼質(zhì)量較差,，問題很多,。他們常常成為項目組的“雞肋”，用多了項目質(zhì)量無法得到保證,，不用則又人手不夠,。

2）人員變動。一個維護時間稍長一點兒的軟件項目,，人員變動是在所難免的,。老員工被調(diào)動到其它項目去了，由新員工來接替他們的工作,。在我的項目組中,，人員調(diào)動達到了90%，唯一沒有調(diào)走的就是我自己,。新員工在接替老員工進行代碼維護,，甚至繼續(xù)進行新的開發(fā)的時，由于對原有代碼以及設(shè)計思路理解的偏差,，也會出現(xiàn)大量的低劣代碼,。

3）不規(guī)范的代碼編寫。即使除去以上兩個問題的影響,，項目組成員編寫的代碼同樣會出現(xiàn)問題,。在項目開發(fā)之初，我們往往會制定一個代碼編寫的規(guī)范,，但在項目開發(fā)過程中,，許多成員往往會忽視這些代碼規(guī)范而進行隨意的編寫。隨意地代碼編寫會降低代碼的可讀性,、可維護性和易變更性,。那么，我們應(yīng)當(dāng)采用什么樣的管理措施,，保證代碼的規(guī)范,，提高代碼的質(zhì)量呢？

以上問題,，也是我在項目開發(fā)中不斷摸索和思考的問題,，而一些有經(jīng)驗的項目經(jīng)理給出了他們的解決之道,，那就是“代碼復(fù)查”。

什么是代碼復(fù)查

代碼復(fù)查（Code Review）,，又叫“代碼審查”,，其基本思想就是，在開發(fā)人員編寫完自己的代碼后,，由其他人來復(fù)查他寫的代碼,，從而有效地發(fā)現(xiàn)代碼中存在的缺陷。代碼復(fù)查的一個基本理論就是,，當(dāng)我們越早發(fā)現(xiàn)代碼存在的缺陷,，我們解決缺陷的代價就越低。代碼復(fù)查往往分成以下一個方面進行審查：

1）代碼風(fēng)格,。在項目開發(fā)之初,，我們往往會制定一個代碼編寫的規(guī)范，實際上,，這個代碼規(guī)范就包含了整個項目組的代碼風(fēng)格,。由于軟件開發(fā)人員的設(shè)計習(xí)慣不同，如果不統(tǒng)一代碼風(fēng)格,，一個項目中的代碼將五花八門,，如變量和常量的命名、接口與實現(xiàn)類的注釋,、何時回車,、怎樣縮進等等。一個五花八門的設(shè)計風(fēng)格,，必將為日后的維護與改進帶來困難,。我們通過代碼復(fù)查，一方面督促開發(fā)人員按照規(guī)范編寫代碼,，另一方面也使開發(fā)人員自身形成良好的編程習(xí)慣,。代碼風(fēng)格的審查，由于內(nèi)容比較單一,，我們常常可以通過一些代碼復(fù)查的工具來自動完成,，提高復(fù)查的效率,。

2）重大缺陷。在一些關(guān)于代碼復(fù)查的文章中,，列出了一個常常的單子,，描述了代碼復(fù)查應(yīng)當(dāng)著重注意的重大缺陷，它們包括：存在SQL注入,、易受跨站點腳本攻擊,、緩存區(qū)溢出,、托管代碼等等。項目組可以不斷積累重大缺陷的審查項目,，并在每次審查中逐一檢查,。重大缺陷審查是一個繁瑣而細致的工作，如果能編寫或使用一些審查軟件,，可以大大提高我們的審查效率,。

3）設(shè)計邏輯與思路的審查。我認為,，這部分的審查是代碼復(fù)查中最核心,、最有價值的部分。代碼風(fēng)格與重大缺陷的審查,，雖然重要但簡單而機械,，可以通過軟件自動檢查；而設(shè)計邏輯與思路的審查,，卻是復(fù)雜而有深度的審查,，需要有一定理論深度和編碼經(jīng)驗的人才能完成，而且對新手尤其重要,。前面提到,，新手是任何項目組不可避免的問題。但遺憾的是,，許多項目經(jīng)理的辦法是,，只將一些簡單而少量的工作交給新手完成，而將大量復(fù)雜的工作交給人數(shù)不多的那些老手來完成,。這樣的結(jié)果是,，新手始終是新手，他們沒有經(jīng)過足夠的鍛煉,；老手累死累活,，無法指望新手予以分擔(dān)工作。對于這個問題,，我的辦法是,，通過代碼復(fù)查，讓老手去指導(dǎo)新手,，讓團隊整體素質(zhì)達到提高,。具體辦法就是，在新手完成編碼以后,，讓老手去進行代碼復(fù)查,，指出新手的問題，指導(dǎo)新手設(shè)計,。這樣的過程最初可能需要重構(gòu),，甚至重新編碼,。但經(jīng)過這樣的過程，新手將逐漸熟練,，迅速成為老手,，使整體團隊素質(zhì)提高。

代碼復(fù)查的形式及優(yōu)缺點

經(jīng)過以上的描述,，我們可以發(fā)現(xiàn)代碼復(fù)查的優(yōu)點顯而易見,。首先，通過對代碼風(fēng)格與規(guī)范的審查,，可以大大提高代碼的可讀性與可維護性?，F(xiàn)在的軟件，往往需要持續(xù)的維護與升級,，人員變動也在所難免,，因此代碼的可讀性與可維護性尤為重要。代碼復(fù)查是一種鞭策,，因為它的存在,，督促著開發(fā)人員自覺地規(guī)范編碼，養(yǎng)成好的編碼習(xí)慣,，提高代碼質(zhì)量,。一個值得注意的問題是，如果你不去讀別人的代碼,，永遠不能深刻理解什么是可讀的代碼,，而自己的代碼不讓別人去讀并且反饋，也永遠不知道自己的代碼是否可讀,，即使你是一個編碼多年的老手,。代碼復(fù)查恰恰解決了這個問題，值得你去嘗試,。

其次,，代碼復(fù)查是一次程序員之間的交流。新手可以有更多的機會向老手學(xué)習(xí)和指導(dǎo),，提高自身的設(shè)計水平（應(yīng)當(dāng)說這對于他們是非常寶貴的）,；老手通過對新手的指導(dǎo)，整理和升華自己的設(shè)計思路與理論,，同時也是對自己另一方面的鍛煉與提高,。另外，當(dāng)你發(fā)現(xiàn)并指出了別人的一個問題以后,，同時也是在警示自己不要犯同樣的錯誤，這對審查與被審查者都是有益的,。

雖然代碼復(fù)查有如此突出的優(yōu)點,，但它的缺點也是非常顯著的,，那就是它需要付出如此巨大的代價。當(dāng)一個人完成編碼以后,，還需要另外的人去解讀和審查,，并要求編程人員完成相應(yīng)的修改，甚至重構(gòu)和重寫,，這本身就是一種巨大的代價,。這對于其本身就已經(jīng)人員和時間非常緊張的軟件開發(fā)項目來說，無疑是一種雪上加霜,。時間,、人力與代碼質(zhì)量，其本身就是魚和熊掌不可兼得,，關(guān)鍵是如何去權(quán)衡,。正因為如此，不同公司選擇了不同的代碼復(fù)查策略,。

前不久,，我聽了韓國一家大型游戲軟件公司談他們的代碼復(fù)查。由于這家公司在軟件開發(fā)時,，時間和人力不是最關(guān)鍵和緊要的問題而代碼質(zhì)量,，所以他們采用了一種嚴(yán)格的代碼復(fù)查策略。嚴(yán)格的代碼復(fù)查策略,，一種方式是由專人進行代碼復(fù)查,。這種方式，在人員組織形式上,，從軟件開發(fā)人員中單獨提出了一些經(jīng)驗豐富的人,，組成一個代碼復(fù)查小組，專職對其它軟件開發(fā)小組進行代碼復(fù)查,。這種方式,，代碼復(fù)查小組以第三方的身份去復(fù)查各個項目組的代碼，可以保證復(fù)查的公平公正,，但壓力無疑是巨大的（想想他們要查看那么多的代碼）,。

另一種方式，是以一個項目開發(fā)小組為單元進行代碼互查,，即一個人的代碼,，要為小組所有成員進行審查。這種方式毫無疑問,，其付出的代價太大了,。對這種方式的一種變通方式是將XP中的結(jié)對編程進行結(jié)合，然結(jié)對編程中的兩個人相互進行代碼互查。采用結(jié)對編程的項目組可以嘗試這樣方式,，遺憾的是目前國內(nèi)采用結(jié)對編程的項目組實在太少了,。以上兩種代碼復(fù)查的最大弊病就是責(zé)任制，即審查者沒有太多的責(zé)任去發(fā)現(xiàn)被審查者的問題,，發(fā)現(xiàn)了問題對審查者沒有任何好處,，反倒與被審查者結(jié)怨；相反,，審查者沒有發(fā)現(xiàn)問題也不會擔(dān)負任何責(zé)任,。這樣的結(jié)果就導(dǎo)致了代碼復(fù)查流于形式：審查者草草審查，各方皆大歡喜,，問題依然存在,。

綜上所述，雖然代碼復(fù)查優(yōu)勢明顯,，但以上幾種形式都不能為普通的軟件開發(fā)團隊所接受,，就此我祭出了我的最佳實踐：以小組為單位，組長責(zé)任制的代碼復(fù)查形式,。

代碼復(fù)查的最佳實踐

代碼復(fù)查是有代價的,，甚至有時是巨大的，因此代碼復(fù)查不宜頻繁,，最好一份代碼只審查一次,。同時，代碼復(fù)查者應(yīng)當(dāng)對所審查的代碼負有責(zé)任,，即能夠大膽地審查并指出被審查者的問題,，并要求被審查者限期整改。與此同時,，被審查后的代碼如果還出現(xiàn)缺陷,，審查者應(yīng)當(dāng)負有責(zé)任。只有滿足了以上三個條件,，代碼復(fù)查才能為我們所接受,。毫無疑問，項目開發(fā)小組的組長來擔(dān)當(dāng)此責(zé)任是最合適的,。

一個項目開發(fā)組,，根據(jù)其功能的劃分，可以劃分為多個小組,，每個小組負責(zé)一個子模塊,。在這樣一個小組中，小組長無疑是最有經(jīng)驗的開發(fā)人員,，由他去負責(zé)組織和指導(dǎo)其它成員是合適的,。小組成員不要太多,，往往是3~5人。小組長不要分配太多的開發(fā)任務(wù),，他的主要工作是指導(dǎo)和監(jiān)督小組其它成員進行開發(fā),。將他從繁重的開發(fā)任務(wù)中解脫出來，他可以有更多的精力去指導(dǎo)其他成員的設(shè)計,，并且復(fù)查他們的代碼。最終,，他要對小組所有成員的代碼質(zhì)量負責(zé),，由項目經(jīng)理或質(zhì)量管理員進行抽查，檢驗其整體情況,。

如果你只是一個小型項目,，人員總共在5人之內(nèi)，那么你不用這樣分組,。作為項目經(jīng)理的你就是那個小組長,，指導(dǎo)和監(jiān)督你的成員。這樣安排是因為在現(xiàn)代的管理理論中認為,，一個人最多只能管理5個人,，超過5個人就應(yīng)當(dāng)分組管理。而如果你在5人之內(nèi)當(dāng)然就不需要分開啦,。

作為組長,，你可以有效地審查和管理你的小組成員。同時,，由于你負有責(zé)任,，你也不得不認真有效地去完成審查工作。通過以上的組織形式,，代碼復(fù)查可以簡便有效地在項目組中開展起來,，從而從管理上有效地提高軟件開發(fā)的代碼質(zhì)量。