最近一直在想如何提高產品質量的方法，其中最重要的一點就是要真正做好“代碼審核”，而不是浮於便面只是為完成公司的流程制度，在這點上不僅我自己要做好，要讓整個團隊也能做好，要讓大家真正通過代碼審核這個活動提升自己，幫助別人。站在當前的角度在為提升團隊代碼審核效果要加強宣貫代碼審核的重要性意義，已有的規范工具方法，團隊成員達成共識。畢竟人才是首要問題，要大家齊心協力才能做好。下面這篇文章感覺很不錯從自身不同的角色成長描述了對代審核的看法，其中穿插了一些不錯的方法，分享一下。
“code review”已經是很多公司的常規實踐，初看上去好像是浪費時間，降低工作效率，其實反之，好處大家有目共睹。它能檢查代碼的正確性，合理性，安全性，發現隱秘的bugs，讓系統更可靠的運行。它能保證代碼能有兩個或以上的人熟悉，促進知識共享。它能讓團隊成員互為備份，互相支持，不會有SPOF。它能威懾埋雷的任何想法，杜絕邪念。它能互相學習好的代碼，提高編程技能。等等。
從畢業開始工作到現在，我對“code review”的認識也越來越深刻，越來越感受到它的重要性，對產品研發的不可缺失。在我的成長過程中，經歷了“code review”的不同角色，每個過程，每個角色，都經歷了很多，積累了經驗。
作為初出茅廬的創業者
從學校畢業不久，出來和朋友一起創業，那時就知道埋頭苦干，不講方法，快速出來產品系統是首要唯一任務。所有的事情都得自己做，加班加點，人也不多，各做各的，相互之間根本沒有什么code review，誰寫好了，誰就commit到代碼庫，經過簡單測試，就可以上線了。不行回滾，修復了再上，完全就是初出茅廬的原始人的做法。那時，經驗不足，考慮不周全，系統經常會出問題。調試bug的過程中，耗時耗力，當時就會有同事一起調試，一起看代碼，最原始的非正式的code review就是那時開始的。當初的經驗教訓就是，debug sucks，test rocks，code review even rockets。
作為代碼提交者
剛出道時，作為新人，更多的是寫代碼和讓高手審查，也慢慢學習怎么審查。
首先，必須了解和學習公司的code review 規范流程。最先學習了不同編程語言的code style，並且要求通過公司的code style測試，也叫做code readability（代碼可讀性）測試。之后一定按照style規定來寫代碼，包括怎么定義變量名，函數名，類名，如何使用空格，怎么寫注釋說明，哪些語法不鼓勵甚至禁止使用，等等，這樣做的好處是提高代碼的可讀性，一致性，可維護性。有了好的訓練，一輩子受益的事情。公司開發了code style檢查工具，使用工具來檢查代碼的可讀性，不符合的立即修正。
寫代碼之前，設計好項目的目錄結構，模塊結構，對象結構，保證代碼的整體結構合理。這樣，別人一看目錄就能知道項目要完成的任務，每個文件要做的事情。
進入編碼階段，先勾畫出大體框架，然后一個一個細化，代碼漂亮，結構合理，算法精致，執行效率高。能復用的盡可能復用，因為那些代碼經過了很多測試，質量有保證。
每寫完一個部分，一定要完善測試用例，主要是白盒單元測試。整體寫完之后，要有集成測試，回歸測試，甚至負載測試，等等。編譯，測試，整合到腳本里面，這樣，每次修改，就能運行腳本自動完成各種測試，保證質量。
一個大項目的各個可以獨立完成的任務，實現和測試好了之后，打包成一個change list，而不是零零散散的，不成系統的，不能獨立運行的一堆代碼。
再次檢查，自己滿意了，才會提交code review。一般，找同項目中的水平高的，能力強的，甚至技術leader，邀請他們來審查，他們能給你更好的建議，讓你學到更多的東西，提高的更快。要求越高越嚴，實際對自己越好。有人經常犯的錯誤是找一個關系好的，或是很隨和的容易通過的，去做自己的code review，以為這樣省事，不會被“批評”，其實，從長遠看是不利於自己發展和提高的。
作為代碼審查者
跟高手交流的過程中，積累了不少code review的經驗，自己也慢慢可以做一些code review的工作了。尤其是當別人改了自己寫的代碼，毋庸置疑會被挑選為第一代碼審查者。
剛開始審查代碼時，會偏重於表層的東西。整體掃描代碼，代碼風格是否滿足，可讀性怎么樣，代碼結構是否合理，是否有懶婆娘裹腳的函數，或是巨大的類，注釋是否清楚，代碼是否重復，是否完成了需求，是否有大的疏漏，等等。如果發現了這些相對容易識別的問題，會打回去，讓作者先修改好，才給做仔細的深度的審查。原則上，如果代碼提交者負責任的話，這類問題應該很少出現。
如果文檔或是需求沒有清楚說明，會和作者討論，了解清楚要完成的任務，和解決辦法，算法。所有這些都清楚了，就可以坐下來好好的讀代碼，想代碼，審查代碼了。
審查代碼時，會一行一行讀下來，理解它，會思考有沒有一些可能出現的問題，邊界情況是否考慮了。會思考如果自己來寫，會怎么實現。如果想到的任何問題，會去檢查測試用例中是否考慮到了。還會關注是否有安全漏洞，代碼的擴展性如何，代碼的執行效率如何，架構是否合理是否一脈相承，對象設計是否合理，在多線程多用戶的情況下是否有問題，等等。很多的都可以作為checklist一項一項檢查。
審查代碼的過程，可不是一個輕松的過程。這時，不但在理解別人的代碼，也是自己在思考如何實現。如果作者的設計和算法和自己不一致，會比較誰的方案更好。如果感覺自己的更好，會和作者討論，建議。
代碼復用，模式提煉是一個應該注意的點。看看代碼的組織是否有利於別人復用，是否可以提取模式，能復用的應該提取出來生成便於復用的形式。再者，由於各人對整個代碼庫的掌握情況不一樣，這時，也會關注作者的代碼有沒有是庫里已經有的，那就應該調用，而不是重復實現，從而減少犯錯。
對於重要的或是難以理解的代碼，會做面對面的code review。對於核心或是critical代碼，會組織code review meeting，大家一起看代碼，這樣，也是一個知識共享的過程。有時候，可能一個代碼，會邀請多人審查，各人會有不懂的見解，發現不同的問題，雖然這樣比較費時，但完成后更能保證質量。
作為管理者
后來，除了上面的角色，還要作為一個管理者，負責規范和實施code review。主要做着以下幾個工作。
首先是制定公司的code review的規范和流程，而且這個必須作為研發的一項政策，要求全體研發必須嚴格執行。比如，類似如下的code review流程。
再者，文檔化不同語言的代碼風格（code style），對於公司常用的語言，都應該有一套，可能有Java，可能有C++，可能有Python，可能有PHP，可能還需要定義腳本語言的風格。這樣，大家有據可循，統一思想和實踐。
根據以前的經驗，定義了一個code review的checklist，相當於一些注意事項都記載下來隨時供參考，這樣，對於主要的檢查點，像安全檢查，多任務多線程，擴展性，復用，OO設計，測試完備性，架構，等等，不會被忽略。其他的點，就可以自由控制和發揮了。比如，類似如下的checklist。
然后，設立簡單易用的code review環境，並將review強制嵌入到代碼提交到代碼庫的命令中。沒有代碼review，沒有審查者的首肯，代碼是沒法commit到代碼庫中的。有人實現了review board ＋ svn 的強制code review的方案，有人實現了 review board ＋ git 的 方案。總之，希望在代碼提交的命令中自動提醒和強制code review，這樣人人都強制遵守，靠的是自動化的程序命令，而不是人。這一點很重要，能法制的，不要人治。
最后，量化效果，包括code review的執行情況，反饋時長，評論數量，反復次數，甚至和測試或是線上的bug系統聯動起來，真正監控code review的質量，獎賞分明。各種指標可視化，放到dashboard上，誰都可以看到。再按指標給代碼提交者和審查者排名，想激勵優秀的，就將好的弄成 star list。想鞭策落后的，就將差的弄成 shame list。
http://mp.weixin.qq.com/s?__biz=MjM5ODIzNDQ3Mw==&mid=2649966104&idx=1&sn=2e9a184beb676cb8687c0bed024fdd62&scene=21#wechat_redirect