如何提高代碼質(zhì)量（管理篇）：代碼復(fù)查
也許你是一位項(xiàng)目經(jīng)理，也許你是一位項(xiàng)目骨干成員，或者開發(fā)小組長。在我發(fā)表“如何提高代碼質(zhì)量”的這一系統(tǒng)文章后，有許多網(wǎng)友都向我抱怨，說他無法把握整個(gè)項(xiàng)目組成員的代碼質(zhì)量。我想，這也是所有項(xiàng)目組普遍存在的問題吧，它通常表現(xiàn)為以下幾個(gè)問題：
軟件項(xiàng)目普遍存在的問題
1）新手。任何項(xiàng)目組成員都不可避免地出現(xiàn)新手，他們往往是剛剛從大學(xué)畢業(yè)的學(xué)生。這些新手由于軟件開發(fā)時(shí)間太短，往往技術(shù)不成熟，沒有形成良好的開發(fā)習(xí)慣，所以編寫代碼質(zhì)量較差，問題很多。他們常常成為項(xiàng)目組的“雞肋”，用多了項(xiàng)目質(zhì)量無法得到保證，不用則又人手不夠。
2）人員變動。一個(gè)維護(hù)時(shí)間稍長一點(diǎn)兒的軟件項(xiàng)目，人員變動是在所難免的。老員工被調(diào)動到其它項(xiàng)目去了，由新員工來接替他們的工作。在我的項(xiàng)目組中，人員調(diào)動達(dá)到了90%，唯一沒有調(diào)走的就是我自己。新員工在接替老員工進(jìn)行代碼維護(hù)，甚至繼續(xù)進(jìn)行新的開發(fā)的時(shí)，由于對原有代碼以及設(shè)計(jì)思路理解的偏差，也會出現(xiàn)大量的低劣代碼。
3）不規(guī)范的代碼編寫。即使除去以上兩個(gè)問題的影響，項(xiàng)目組成員編寫的代碼同樣會出現(xiàn)問題。在項(xiàng)目開發(fā)之初，我們往往會制定一個(gè)代碼編寫的規(guī)范，但在項(xiàng)目開發(fā)過程中，許多成員往往會忽視這些代碼規(guī)范而進(jìn)行隨意的編寫。隨意地代碼編寫會降低代碼的可讀性、可維護(hù)性和易變更性。那么，我們應(yīng)當(dāng)采用什么樣的管理措施，保證代碼的規(guī)范，提高代碼的質(zhì)量呢？
以上問題，也是我在項(xiàng)目開發(fā)中不斷摸索和思考的問題，而一些有經(jīng)驗(yàn)的項(xiàng)目經(jīng)理給出了他們的解決之道，那就是“代碼復(fù)查”。
什么是代碼復(fù)查
代碼復(fù)查（Code Review），又叫“代碼審查”，其基本思想就是，在開發(fā)人員編寫完自己的代碼后，由其他人來復(fù)查他寫的代碼，從而有效地發(fā)現(xiàn)代碼中存在的缺陷。代碼復(fù)查的一個(gè)基本理論就是，當(dāng)我們越早發(fā)現(xiàn)代碼存在的缺陷，我們解決缺陷的代價(jià)就越低。代碼復(fù)查往往分成以下一個(gè)方面進(jìn)行審查：
1）代碼風(fēng)格。在項(xiàng)目開發(fā)之初，我們往往會制定一個(gè)代碼編寫的規(guī)范，實(shí)際上，這個(gè)代碼規(guī)范就包含了整個(gè)項(xiàng)目組的代碼風(fēng)格。由于軟件開發(fā)人員的設(shè)計(jì)習(xí)慣不同，如果不統(tǒng)一代碼風(fēng)格，一個(gè)項(xiàng)目中的代碼將五花八門，如變量和常量的命名、接口與實(shí)現(xiàn)類的注釋、何時(shí)回車、怎樣縮進(jìn)等等。一個(gè)五花八門的設(shè)計(jì)風(fēng)格，必將為日后的維護(hù)與改進(jìn)帶來困難。我們通過代碼復(fù)查，一方面督促開發(fā)人員按照規(guī)范編寫代碼，另一方面也使開發(fā)人員自身形成良好的編程習(xí)慣。代碼風(fēng)格的審查，由于內(nèi)容比較單一，我們常?？梢酝ㄟ^一些代碼復(fù)查的工具來自動完成，提高復(fù)查的效率。
2）重大缺陷。在一些關(guān)于代碼復(fù)查的文章中，列出了一個(gè)常常的單子，描述了代碼復(fù)查應(yīng)當(dāng)著重注意的重大缺陷，它們包括：存在SQL注入、易受跨站點(diǎn)腳本攻擊、緩存區(qū)溢出、托管代碼等等。項(xiàng)目組可以不斷積累重大缺陷的審查項(xiàng)目，并在每次審查中逐一檢查。重大缺陷審查是一個(gè)繁瑣而細(xì)致的工作，如果能編寫或使用一些審查軟件，可以大大提高我們的審查效率。
3）設(shè)計(jì)邏輯與思路的審查。我認(rèn)為，這部分的審查是代碼復(fù)查中最核心、最有價(jià)值的部分。代碼風(fēng)格與重大缺陷的審查，雖然重要但簡單而機(jī)械，可以通過軟件自動檢查；而設(shè)計(jì)邏輯與思路的審查，卻是復(fù)雜而有深度的審查，需要有一定理論深度和編碼經(jīng)驗(yàn)的人才能完成，而且對新手尤其重要。前面提到，新手是任何項(xiàng)目組不可避免的問題。但遺憾的是，許多項(xiàng)目經(jīng)理的辦法是，只將一些簡單而少量的工作交給新手完成，而將大量復(fù)雜的工作交給人數(shù)不多的那些老手來完成。這樣的結(jié)果是，新手始終是新手，他們沒有經(jīng)過足夠的鍛煉；老手累死累活，無法指望新手予以分擔(dān)工作。對于這個(gè)問題，我的辦法是，通過代碼復(fù)查，讓老手去指導(dǎo)新手，讓團(tuán)隊(duì)整體素質(zhì)達(dá)到提高。具體辦法就是，在新手完成編碼以后，讓老手去進(jìn)行代碼復(fù)查，指出新手的問題，指導(dǎo)新手設(shè)計(jì)。這樣的過程最初可能需要重構(gòu)，甚至重新編碼。但經(jīng)過這樣的過程，新手將逐漸熟練，迅速成為老手，使整體團(tuán)隊(duì)素質(zhì)提高。
代碼復(fù)查的形式及優(yōu)缺點(diǎn)
經(jīng)過以上的描述，我們可以發(fā)現(xiàn)代碼復(fù)查的優(yōu)點(diǎn)顯而易見。首先，通過對代碼風(fēng)格與規(guī)范的審查，可以大大提高代碼的可讀性與可維護(hù)性?，F(xiàn)在的軟件，往往需要持續(xù)的維護(hù)與升級，人員變動也在所難免，因此代碼的可讀性與可維護(hù)性尤為重要。代碼復(fù)查是一種鞭策，因?yàn)樗拇嬖冢酱僦_發(fā)人員自覺地規(guī)范編碼，養(yǎng)成好的編碼習(xí)慣，提高代碼質(zhì)量。一個(gè)值得注意的問題是，如果你不去讀別人的代碼，永遠(yuǎn)不能深刻理解什么是可讀的代碼，而自己的代碼不讓別人去讀并且反饋，也永遠(yuǎn)不知道自己的代碼是否可讀，即使你是一個(gè)編碼多年的老手。代碼復(fù)查恰恰解決了這個(gè)問題，值得你去嘗試。
其次，代碼復(fù)查是一次程序員之間的交流。新手可以有更多的機(jī)會向老手學(xué)習(xí)和指導(dǎo)，提高自身的設(shè)計(jì)水平（應(yīng)當(dāng)說這對于他們是非常寶貴的）；老手通過對新手的指導(dǎo)，整理和升華自己的設(shè)計(jì)思路與理論，同時(shí)也是對自己另一方面的鍛煉與提高。另外，當(dāng)你發(fā)現(xiàn)并指出了別人的一個(gè)問題以后，同時(shí)也是在警示自己不要犯同樣的錯(cuò)誤，這對審查與被審查者都是有益的。
雖然代碼復(fù)查有如此突出的優(yōu)點(diǎn)，但它的缺點(diǎn)也是非常顯著的，那就是它需要付出如此巨大的代價(jià)。當(dāng)一個(gè)人完成編碼以后，還需要另外的人去解讀和審查，并要求編程人員完成相應(yīng)的修改，甚至重構(gòu)和重寫，這本身就是一種巨大的代價(jià)。這對于其本身就已經(jīng)人員和時(shí)間非常緊張的軟件開發(fā)項(xiàng)目來說，無疑是一種雪上加霜。時(shí)間、人力與代碼質(zhì)量，其本身就是魚和熊掌不可兼得，關(guān)鍵是如何去權(quán)衡。正因?yàn)槿绱耍煌具x擇了不同的代碼復(fù)查策略。
前不久，我聽了韓國一家大型游戲軟件公司談他們的代碼復(fù)查。由于這家公司在軟件開發(fā)時(shí)，時(shí)間和人力不是最關(guān)鍵和緊要的問題而代碼質(zhì)量，所以他們采用了一種嚴(yán)格的代碼復(fù)查策略。嚴(yán)格的代碼復(fù)查策略，一種方式是由專人進(jìn)行代碼復(fù)查。這種方式，在人員組織形式上，從軟件開發(fā)人員中單獨(dú)提出了一些經(jīng)驗(yàn)豐富的人，組成一個(gè)代碼復(fù)查小組，專職對其它軟件開發(fā)小組進(jìn)行代碼復(fù)查。這種方式，代碼復(fù)查小組以第三方的身份去復(fù)查各個(gè)項(xiàng)目組的代碼，可以保證復(fù)查的公平公正，但壓力無疑是巨大的（想想他們要查看那么多的代碼）。
另一種方式，是以一個(gè)項(xiàng)目開發(fā)小組為單元進(jìn)行代碼互查，即一個(gè)人的代碼，要為小組所有成員進(jìn)行審查。這種方式毫無疑問，其付出的代價(jià)太大了。對這種方式的一種變通方式是將XP中的結(jié)對編程進(jìn)行結(jié)合，然結(jié)對編程中的兩個(gè)人相互進(jìn)行代碼互查。采用結(jié)對編程的項(xiàng)目組可以嘗試這樣方式，遺憾的是目前國內(nèi)采用結(jié)對編程的項(xiàng)目組實(shí)在太少了。以上兩種代碼復(fù)查的最大弊病就是責(zé)任制，即審查者沒有太多的責(zé)任去發(fā)現(xiàn)被審查者的問題，發(fā)現(xiàn)了問題對審查者沒有任何好處，反倒與被審查者結(jié)怨；相反，審查者沒有發(fā)現(xiàn)問題也不會擔(dān)負(fù)任何責(zé)任。這樣的結(jié)果就導(dǎo)致了代碼復(fù)查流于形式：審查者草草審查，各方皆大歡喜，問題依然存在。
綜上所述，雖然代碼復(fù)查優(yōu)勢明顯，但以上幾種形式都不能為普通的軟件開發(fā)團(tuán)隊(duì)所接受，就此我祭出了我的最佳實(shí)踐：以小組為單位，組長責(zé)任制的代碼復(fù)查形式。
代碼復(fù)查的最佳實(shí)踐
代碼復(fù)查是有代價(jià)的，甚至有時(shí)是巨大的，因此代碼復(fù)查不宜頻繁，最好一份代碼只審查一次。同時(shí)，代碼復(fù)查者應(yīng)當(dāng)對所審查的代碼負(fù)有責(zé)任，即能夠大膽地審查并指出被審查者的問題，并要求被審查者限期整改。與此同時(shí)，被審查后的代碼如果還出現(xiàn)缺陷，審查者應(yīng)當(dāng)負(fù)有責(zé)任。只有滿足了以上三個(gè)條件，代碼復(fù)查才能為我們所接受。毫無疑問，項(xiàng)目開發(fā)小組的組長來擔(dān)當(dāng)此責(zé)任是最合適的。
一個(gè)項(xiàng)目開發(fā)組，根據(jù)其功能的劃分，可以劃分為多個(gè)小組，每個(gè)小組負(fù)責(zé)一個(gè)子模塊。在這樣一個(gè)小組中，小組長無疑是最有經(jīng)驗(yàn)的開發(fā)人員，由他去負(fù)責(zé)組織和指導(dǎo)其它成員是合適的。小組成員不要太多，往往是3~5人。小組長不要分配太多的開發(fā)任務(wù)，他的主要工作是指導(dǎo)和監(jiān)督小組其它成員進(jìn)行開發(fā)。將他從繁重的開發(fā)任務(wù)中解脫出來，他可以有更多的精力去指導(dǎo)其他成員的設(shè)計(jì)，并且復(fù)查他們的代碼。最終，他要對小組所有成員的代碼質(zhì)量負(fù)責(zé)，由項(xiàng)目經(jīng)理或質(zhì)量管理員進(jìn)行抽查，檢驗(yàn)其整體情況。
如果你只是一個(gè)小型項(xiàng)目，人員總共在5人之內(nèi)，那么你不用這樣分組。作為項(xiàng)目經(jīng)理的你就是那個(gè)小組長，指導(dǎo)和監(jiān)督你的成員。這樣安排是因?yàn)樵诂F(xiàn)代的管理理論中認(rèn)為，一個(gè)人最多只能管理5個(gè)人，超過5個(gè)人就應(yīng)當(dāng)分組管理。而如果你在5人之內(nèi)當(dāng)然就不需要分開啦。
作為組長，你可以有效地審查和管理你的小組成員。同時(shí)，由于你負(fù)有責(zé)任，你也不得不認(rèn)真有效地去完成審查工作。通過以上的組織形式，代碼復(fù)查可以簡便有效地在項(xiàng)目組中開展起來，從而從管理上有效地提高軟件開發(fā)的代碼質(zhì)量。
