什麼是代碼Review?
代碼review是指在軟件開發過程中，通過對源代碼進行系統性檢查來確認代碼實現的質量保證機制
爲什麼不做代碼Review?
業務需求大，工作時間緊張
項目小，協作的人少，沒必要
爲什麼要做代碼Review?
提高代碼質量，提升自身水平
及早發現潛在缺陷與BUG，降低事故成本
促進團隊內部知識共享，提高團隊整體水平
保證項目組人員的良好溝通
避免開發人員犯一些很常見，很普通的錯誤
總而言之目的是查找系統缺陷，保證軟件總體質量和提高開發者自身水平，使項目代碼更加容易維護。
代碼Review的好處
在代碼提交之前如果有很多雙眼睛盯着看可以發現bug，這是代碼審查最廣爲人知的好處。（人們的確可以在代碼審查中發現bug，但是這些bug大部分都是顯而易見的小bug，開發者分分鐘可以發現，而那些真正需要花時間發現的bug通常是在代碼審查中發現的）
代碼審查最大的好處是純社會性的。（如果你編程的時候知道你的同事將要看你的代碼，你的編程方式會不一樣，你的代碼會寫的更整潔，註釋更加清楚，組織得更好。因爲你知道其他人會看你的代碼，他們的意見是你需要關注的。如果沒有審查，你雖然知道人們最後會去看你的代碼，但是那樣不會給你一種緊迫感，也不會給你同樣的個人評判的感覺。）
還有一個更大的好處就是代碼審查可以傳播知識。（在很多開發小組裏，每個人都負責某一個核心組件，專注於自己的這一塊，只要其他同事的模塊不會破壞自己的代碼就不會去關注，這種模式導致一個模塊只有一個人熟悉對應的代碼，如果一個人請教或者離職，其他人對他負責的模塊將一無所知。如果採用代碼審查，那麼至少有兩個人熟悉代碼-作者和審查者。審查者知道的代碼不如作者多，但是他們都熟悉代碼的設計和結構，這意義重大）
Code Review的前提
重視代碼review
(Code Review人員是否理解了Code Review的概念和Code Review將做什麼如果做Code Review的人員不能理解Code Review對項目成敗和代碼質量的重要程度，他們的做法可能就會是應付了事。)代碼是否已經正確的build，build的目的使得代碼已 經不存在基本語法錯誤
(我們總不希望高級開發人員或是主管將時間浪費在檢查連編譯都通不過的代碼上吧。 )代碼執行時功能是否正確
(Code Review人員也不負責檢查代碼的功能是否正確，也就是說，需要複查的代碼必須由開發人員或質量人員負責該代碼的功能的正確性。 )開發人員是否對代碼做了單元測試
(這一點也是爲了保證Code Review前一些語法和功能問題已經得到解決，Code Review人員可以將精力集中在代碼的質量上。 )
Code Review需要注意什麼？
完整性檢查（Completeness）
代碼是否完全實現了設計文檔中提出的功能需求
代碼是否已按照設計文檔進行了集成和Debug
代碼是否已創建了需要的數據庫,包括正確的初始化數據
代碼中是否存在任何沒有定義或沒有引用到的變量、常數或數據類型一致性檢查（Consistency）
代碼的邏輯是否符合設計文檔
代碼中使用的格式、符號、結構等風格是否保持一致正確性檢查（Correctness）
所有的變量都被正確定義和使用
所有的註釋都是準確的
所有的程序調用都使用了正確的參數個數可修改性檢查（Modifiability）
代碼涉及到的常量是否易於修改(如使用配置、定義爲類常量、使用專門的常量類等)
代碼是否只有一個出口和一個入口（嚴重的異常處理除外）健壯性檢查（Robustness）
可理解性檢查（Understandability）
註釋是否足夠清晰的描述每個子程序
是否使用到不明確或不必要的複雜代碼，它們是否被清楚的註釋
使用一些統一的格式化技巧（如縮進、空白等）用來增強代碼的清晰度
是否在定義命名規則時採用了便於記憶，反映類型等方法
每個變量都定義了合法的取值範圍
代碼中的算法是否符合開發文檔中描述的數學模型可驗證性檢查(Verifiability)
代碼中的實現技術是否便於測試
Code Review經驗檢查項
1、 編碼規範方面檢查項
2、面向對象設計方面檢查項
類設計和抽象是否合適
是否符合面向接口編程的思想
是否採用合適的設計模式
3、性能方面檢查項
對hashtable,vector等集合類數據結構的選擇和設置是否合適
有無濫用String對象的現象
是否採用通用的線程池、對象池模塊等cache技術以提高性能
I/O方面是否使用了合適的類或採用良好的方法以提高性能（如減少序列化，使用buffer類封裝流等）
同步方法的使用是否得當,是否過度使用
4、數據庫處理方面
數據庫資源是否正常關閉和釋放
數據庫訪問模塊是否正確封裝，便於管理和提高性能
是否採用合適的事務隔離級別
資源泄漏處理方面檢查項 cursor
5、通訊方面檢查項
- socket通訊是否存在長期阻塞問題
6、重複代碼
7、其他
日誌是否正常輸出和控制
配置信息如何獲得,是否有硬編碼
怎麼更有效的做Code Review
一次評審量要低於 200–400 行代碼缺陷密度 就是每 1000 行代碼之中所發現的錯誤（bug）數
每小時低於 300–500 LOC 檢查率的目標
花足夠的時間進行適當緩慢的評審，但是不要超過 60-90 分鐘
但反過來說，評審代碼所花的時間不得低於五分鐘，就算代碼只有一行也是如此。通常來說，單行的代碼也會影響到整個的系統，所以花上五分鐘時間去檢查更改可能造成的結果是值得的
確定在評審開始之前代碼開發者已經註釋源代碼了
使用檢查表，因爲它能極大地影響代碼開發者和評審者的結果
另外一個有用的概念就是 個人檢查表 。每個人一般都會犯 15-20 個錯誤（bug）。如果您注意到了一些典型的錯誤（bug），那麼您就可以開發自己的個人檢查表
確認缺陷得到了修復
最後，讓Code Review成爲一種習慣！
參考目錄：
1. 代碼Review那些事