【前言】

      百度百科上說：“代碼評審也稱代碼復查，是指通過閱讀代碼來檢查源代碼與編碼標準的符合性以及代碼質量的活動。”這篇百科的內容好像是幾年前CSDN上的一篇博文，但不管他們怎么抄，代碼評審大概就是這么個意思。

      代碼評審，沒多大點事，貌似可有可無，但不管你怎么回避，確實不能也無法做到視而不見。

【代碼評審的尷尬】

      最典型的介紹代碼評審的開展方法就是：搞個3、5個人，什么小組長、秘書、測試人員啦，然后開會什么的。于是代碼評審變成了會議，開發人員多數是技術宅、務實派，比較反感這種貌似能解決問題卻往往更加添亂的口水活動，于是這事自然成了形式。借用一網友的圖片，會議的初衷是好的，但往往過于理想化：

      圖左 - 心目中的會議是這樣的（圖片來自網友博客）               圖右 - 實際上的會議卻往往是這樣

      一直以來，個人對代碼評審非常認同，身體力行，且行之有效。雖然實際推行的范圍和力度根據實際情況有所保留，但這往往是基于團隊成員的意識、開發目標類型的差異而作出的裁剪。

      代碼評審，其實是開發人員某種程度上追求卓越的一種體現，專業與業余的區別，往往在于細節。實現同樣的需求，拋去什么高瞻遠矚的詞藻，Martin Fowler寫出的代碼應該很容易就能跟一吊兒郎當的猿類區分開來，與其說是職業素養，不如說是習慣而已，敲出的是代碼其實傾注的是感情。

      網上偶爾出現的有關代碼評審的討論貼，往往充滿火藥味，爭論的焦點莫不是：要不要評審、評審到底有沒有好處、怎么評審。但對要評審的對象、所使用的評價目標、要達到的期望往往混為一談，最終幾百個回貼下來，還是得不出明確的結論。

【不要期望過高，務實是上策】

      每個公司每個團隊都有各自特點，作為政策推行者，盡信書不如無書，須要跳出書本理論，結合團隊的實際，摸索出自已的方法。我始終認為，適合的才是最好的。

      不要期望代碼評審能一下子改變現狀，但無疑，推比不推強，怎么推、推到什么程序度則另說。能看到效果，無論多少都是進步，循序漸進，貴在堅持。

      不要心急，正如所有的政策推行一樣，它應該是一個從弱到強、不斷迭代的過程。先期重在培養和灌輸一種意識，等大家的潛意識里基本認同后再進入下一階段，否則還是先觀察做細微調整后再說。切忌一蹴而就、強力推行，否則結果將很難看。團隊對你的信任又要少一分了，管理者手上的牌其實不多，浪費一張少一張，團隊成員的信任和耐心消磨一點少一點。

【解決之道1：先把代碼按所屬類型分類】

      代碼評審作為一項活動，從程序員的視角可以這樣理解，它由3個組成要素：輸入是“要評審的對象”、輸出是“期望的結果”、而“評審判定的標準”就是你設定好的測試用例。

      作為傳統的軟件開發公司，我是這么干的，把要評審的代碼所屬的工程項目分為3類：

    [第1類] - 要進入公司可重用開發平臺（通用類）的代碼

      描述：這些代碼是公司歷經多年的積累，逐漸提煉而成。它是公司技術資產的核心所在、立足之本。

      評價標準：注釋完備、代碼結構能運用常用的設計模式、接口的設計合理且有一定的前瞻性。

      前瞻性這個詞很文藝，如何評價呢？我是這么理解的：前瞻性意味現在不需要的邏輯不代表永遠不需要，但無需面面俱到，能解決絕大部分一般情況、也能解決少數的特殊情況、且能為無      法解決的情況提供一個規避方法為前提，因為通用類不是哪么輕易就可修改的。開發平臺盡量物以類聚：完成同類或相似類別問題的代碼盡量歸類，盡量減小不同模塊間的偶合，且能形成互相獨立的子模塊為最佳（你所抽取出來的子模塊可應用于同類技術的各種場景而不限于該開發平臺）——化整完零減小復雜度提高重用的可能性。

如果軟件代碼可以度量評分，如果最佳是100分，此類代碼應至少達到80分及以上。你可能要問，這80分的標準貌似還是有點虛，確實如此，能把握到什么程度也只能全靠這平臺的技術執掌人的個人技術修為了。

      評審的主持人和參與者：這部分代碼無疑對公司而言具有最高密級，不是所有人都能看到的，所以主持人最好是公司技術的最高級別負責人，參與者限于公司參與維護這類代碼的開發者為佳，參與人員的范圍越小越好，評審的強度當然是越大越好。

    [第2類] - 要進入公司標準產品的代碼

      描述：此類工程不僅可能會作為公司的直接營收來源，它還會作為客戶定制項目的基礎而存在。

      它的質量首先由前面的基礎開發平臺進行了保證，要評審的代碼應該絕大多數都是業務相關代碼，此類代碼不求技術高超，但求代碼規范，但一定的擴展性等問題也是不可回避的——它可能會決定定制項目的開發難度（甚至開發的可行性）。

      評價標準：注釋較完備、關鍵業務及邏輯必須進行完善地注釋（甚至要能關聯到原始需求，比如JIRA中的Issue等）、任何被調用2次及以上的代碼必須要抽取成單獨的方法或類等等、規范的編碼習慣（那大段的空白、連縮進都沒做好的代碼，顯然不能避過）、各種代碼應按業務或一定的邏輯進行分包歸類、各種代碼的命名（包括類名、方法名）也應遵循一個大家一致約定的命名規則（遵循一致的命名規則和約定就跟為什么那么多公司一定要用各種框架的道理是一樣的——提高代碼理解的互通性、降低上手門檻），盡量做到見名知義。

      這些代碼不求技術高超，但求代碼規范，代碼質量應能達到60分及以上（至于何為60分，真沒法度量，全憑技術執掌人的技術修為和直覺了）。

      評審的主持人和參與者：這些代碼也屬公司有重大價值的資產，因而也是不應大范圍擴散，公司技術負責人、產品技術負責人來保證所有代碼的整體框架和質量、各參與開發的開發者作為評審參與人即可。

    [第3 類] - 基于標準產品的以客戶定制為目標的商業項目

      描述：此類項目是公司的營收來源，代碼的質量倒是其次，關鍵在于成本、交付期、交付質量等幾方面的博弈和平衡，在資源充足（這個資源是廣義的：比如時間、金錢等）的情況下當然項目的代碼質量越高越好，但很多時候沒有必要。

      評價標準：在時間充足且考慮到該項目還需要后期維護的情況下保證代碼沒有明顯缺陷、代碼編寫都較為規范、一般業務注釋較齊備、關鍵業務注釋較詳細也就可以算得上高代碼質量的產品了，但如果成本壓力大、交付期很緊的情況下，則具備一定的應用品質且能盡快交付為佳，至于代碼質量則排在后面再考慮吧，畢竟所謂高質量代碼是為了后期的維護方便，在目前條件受限的情況下，先滿足最基本的要求才是上上策。

      評審的主持人和參與者：公司最高技術負責人作為外圍推動者，項目組的最高技術負責人為主持者，具體開發人員為參與者，盡量做到簽入的代碼都是經過評審的（至少要經過項目技術負責人的檢視，至于過程有是細致還是精糙，則應依情況而定，做總不比做強）。

【解決之道2：潤物細無聲】

      對于未知或暫時未知的事物，人都有一種或多或少的恐懼感。就拿學習一項新技術，剛聽到這個名詞的時候，心里琢磨：這東西貌似不簡單。忽然有一天公司急用，心里咯噔一下——慌了，接下來腦海里必然出現3個字——“怎么辦？”但當你真正花點時間仔細琢磨并逐漸入門之后，恍然大悟——“原來如此！”頓感親切無比。

      代碼評審也一樣，沒必要成天把名字掛在嘴邊，說白了不就是看代碼嗎。作為技術管理者，就像給鬧鐘緊發調，今天緊一點，明天再緊一點，后再更緊一點，逐漸從點到面，積少成多，等大家都形成了習慣，生米也成熟飯了。至于它叫不叫“代碼評審”，還有關系嗎？關鍵在于，目的達到了，而且在大家不知不覺中，推行幾乎沒阻力。且張弛有度，最近一段時間貌似路走的有點偏，稍微調整一下，團隊實在無藥可救則慢慢撤下也是不知不覺。

      推行之初又是開會，又是討論的，這調定的太高，真若操作不當，如何下的了臺？作為技術管理者保持一定的權威還是有必要的，無論事大事小，搞砸了，必然在下屬或團隊成員面前形象多少受損，得不償失。

【解決之道3：我的實踐】

      代碼評審，就跟公司里的很多政策一樣，不推不行，強推更不行，沒人支持的政策遲早淪為形式。

      代碼評審與其說評的是代碼，不如說是評責任心，責任心是一個人的職業操守要素之一。沒有責任心的人爛泥糊不上墻，你休想改造他（所以這也扯到招聘的事了，人品是前提，其次再談技術，關于招聘的問題以后的文章里再詳細討論）。

      如果在逐級下推的過程中遇到不理解或不配合，也無需灰心，先不要強行下推，放放看看，柿子先撿軟的捏（嘿嘿），這些意識遲早會傳染給這些目前還啃不下來的骨頭。

      代碼評審，其實講究的是從自我做起，每個人對自已嚴格要求這事也就省不少了。所以根本問題還在于，嚴格要求應是這種團隊的基本文化。換句話講，自由散漫的團隊，代碼評審這活似乎有點不搭調，你說呢？還不如先把基本團隊精神確立，再來談也不遲。

【解決之道4：評審過程中不可忽視的原則】

      1）代碼評審，它只是開發人員的事：

      很多文章里寫到，要把測試人員納入進來，很多理論里其實又講要讓測試人獨立于開發技術細節之外，從而能從不同于開發人員的視角找出bug，這樣的言論無疑是矛盾的。至于測試人員怎么安排，不在本文討論之列，但代碼評審這個事，似乎真與測試人員沒多大關系。開發人員保證代碼的質量，無可厚非，而且能一定程度提升他們的責任感，而且面對代碼這本身就是他們的長處，專者盡其才，方可發揮最大效力。

      2）代碼評審，最好不要跟業務掛上勾：

      首先說明，評審過程中能跟業務掛上勾其實是最能達到評審效果的方式，但缺點在于，評審人員讀別人代碼的前提是要先理解業務邏輯。 這要求就高了點，干過開發的都有體會——寫代碼往往比理解業務要容易（但也不盡然），如果要把理解業務作為前提，與其說是評審代碼，不如說是學習業務。我估計這事十有八九要遇到不小的阻力，開發人員都很懶（呵呵），能省則省，能避就避，讓他們干完本職工作還得額外痛苦一回，你說他樂不樂意？

      3）做這事前，最好得到直接上司的理解：

      如果你是公司CTO或技術總監倒問題不大，但如果你是項目經理或項目組內的架構師等，則干這事你得掂量掂量，如果你直接上司與你一拍即合那當然沒話說，如果上司自已對這事也不痛不癢，甚至公司從上至下的技術文化就是散漫自由型，那你還是趁早收手做好自已為上，這爹不痛娘不愛的事，呵呵就不往下說了。。。

      4）對事不對人：

      那就是評審的目的是為了提高代碼的質量，而不是找誰的茬，這種心態必須貫穿始終。

      5）盡量避免相同或相近水平的開發者互審代碼：

      兩個半吊子，自已的見地和知識水平本身就有限，他們作為觀察者進行學習才是最要做的事，真要讓他們參與進來那就不太靠譜了：因為他們自已都不太不相信憑已之力能改變別人的代碼質量，你覺得他們會正確認識這件事嗎？這事還不得慢慢黃了？所以評審的主持者或評審人應至少是技術相比高一層次的人員，否則不如不做。其實代碼評審就也是一個學習的過程，傳、跟、幫、帶，這事靠譜。

      6）簽入的代碼盡快進行評審：

      代碼是有版本和時效性的，壞的習慣可以傳染，這次沒注意到的壞毛病經過漫延往后很可能就泛濫了。尤其在項目組組建的早期新進人員較多的情況，尤其要盡快進行——即時糾正不良習慣、約束大家形成一致的步調。盡快查復、隨時隨地復查、非正式復查等等形式，總之是要把復查的工作量化于平時的工作中，避免積少成多，到最后積壓成不可能完成的負擔。其實好的習慣也是可以傳染的，在項目早期糾正了一些不規范，越往后期這樣的問題會越來越少，從而形成良性循環。

      7）評價標準一定要有：

      標準很重要，對于公司核心平臺標準應由技術負責人個人把握（那就得看他的技術修為了），對于產品和項目則應有公司統一的基本編碼規范和一些約定俗成的東西等，一些典型的優質產品或項目可以作為標桿，供學習和培訓用，沒有燈塔，如何前行？

      8）標準一經確立，都應無條件遵守：

      一旦確立了標準，則任何有關人員都應遵從。標準可能有缺陷，你有權提出改進，但一經確認，就得無條件遵從，這就是所謂的管理有方了。

【解決之道5：借助工具，放大生產力】

      努力很重要，方法更重要，而工具的使用往往是方法能否成功落地的關鍵。經過較長一段時間的實踐，目前主要使用了以下這些工具，效果都還不錯：

      1）JIRA：作為項目管理工具的核心，它可以管理需求、任務分配、任務跟蹤、結果統計、版本發布、與Fisheye/Crucible組合，可很好地實現工程代碼的變更和代碼評審，非常好用；

      2）Greenhopper：它其實是JIRA的一個插件，適合于敏捷開發團隊使用；

      3）Fisheye：它是JIRA同一公司下的產品，可以很容易獲知整個工程里任何一個資源的變更情況，與Crucible同時使用可以很好地生成代碼評審活動；

      4）Crucible：同Fisheye一樣，同一家公司的產品，代碼評審利器；

      5）IMO：國產企業辦公用的即時通和協同辦公軟件，用起來不錯，更重要的是免費，貌似還跟企鵝吵過架；

      6）知識庫Discuz論壇：其實另一名為Conflurence的產品也是JIRA同一公司產品，可以很好的集成。但經過評估，最終還是采用國人開發的免費論壇，好處是對國人而言實在是太熟悉了，推廣難度自然小許多。這東西用的好的話從某種角度講比Conflurence要強大太多了：權限控制還不錯、知識分享、文檔資源歸類下載、各種自由討論等等，還可以鼓勵個人有時間寫寫日志（密送或公開），對公司范圍或團隊范圍內的交流有很大的幫助。

      以上這些工具，首先申明不是為它們作廣告，如果你這么感覺請忽略之。不一定適合所有團隊，還是那句話，適合的才是最好的。有時間還想針對這些工具的安裝和使用寫寫文章，不得不說，安裝、使用、組合的過程確實有點折騰人，但好東西誰想錯過啊，呵呵。

【感悟】

      很多時候，當你低著頭一直往前苦苦找尋你的答案，卻往往得不到你想要的，當你擔起頭準備放棄的時候，回頭一看，哦，原來答案就在起點不遠處。化繁為簡，跳出固有思維，往往答案就在你的腳下。。。

【關于作者】

      寫的是項目管理，又何止于此。作者Jack Jiang，有過艱難創業的經歷、也親歷過優秀公司的起起落落，且至今仍在摸索中前行，始終心懷感恩，期待著下一次的機遇和挑戰。拙筆劣字，與君共勉。

--------------------------------------------------------------------------------------------------
附件1：JIRA系統 

附件2：Fisheye+Crucible系統