歡迎您光臨本站 註冊首頁

如何提高代碼質量(管理篇):代碼複查

←手機掃碼閱讀     火星人 @ 2014-03-12 , reply:0
  

 來源:范鋼的博客

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

軟體項目普遍存在的問題

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

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

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

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

什麼是代碼複查

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

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

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

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

代碼複查的形式及優缺點

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

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

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

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

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

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

代碼複查的最佳實踐

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

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

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

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



[火星人 ] 如何提高代碼質量(管理篇):代碼複查已經有392次圍觀

http://coctec.com/docs/program/show-post-71315.html