也許你是一位項目經理，也許你是一位項目骨干成員，或者開發小組長。在我發表“如何提高代碼質量”的這一系列文章后，有許多網友都向我抱怨，說他無法把握整個項目組成員的代碼質量。我想，這也是所有項目組普遍存在的問題吧，它通常表現為以下幾個問題：

　　軟件項目普遍存在的問題

　　1）新手

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

　　2）人員變動

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

　　3）不規范的代碼編寫

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

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

　　什么是代碼復查

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

　　1）代碼風格

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

　　2）重大缺陷

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

　　3）設計邏輯與思路的審查

　　我認為，這部分的審查是代碼復查中最核心、最有價值的部分。代碼風格與重大缺陷的審查，雖然重要但簡單而機械，可以通過軟件自動檢查；而設計邏輯與思路的審查，卻是復雜而有深度的審查，需要有一定理論深度和編碼經驗的人才能完成，而且對新手尤其重要。前面提到，新手是任何項目組不可避免的問題。但遺憾的是，許多項目經理的辦法是，只將一些簡單而少量的工作交給新手完成，而將大量復雜的工作交給人數不多的那些老手來完成。這樣的結果是，新手始終是新手，他們沒有經過足夠的鍛煉；老手累死累活，無法指望新手予以分擔工作。

　　對于這個問題，我的辦法是，通過代碼復查，讓老手去指導新手，讓團隊整體素質得到提高。具體辦法就是，在新手完成編碼以后，讓老手去進行代碼復查，指出新手的問題，指導新手設計。這樣的過程最初可能需要重構，甚至重新編碼。但經過這樣的過程，新手將逐漸熟練，迅速成為老手，使整體團隊素質提高。

　　代碼復查的形式及優缺點

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

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

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

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

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

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

　　代碼復查的最佳實踐

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

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

　　如果你只是一個小型項目，人員總共在5人之內，那么你不用這樣分組。作為項目經理的你就是那個小組長，指導和監督你的成員。這樣安排是因為在現代的管理理論中認為，一個人最多只能管理5個人，超過5個人就應當分組管理。而如果你在5人之內當然就不需要分開啦。

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