a)可以在項目早期就能夠發現代碼中的BUG ，提測後可以儘快的釋放開發資源；
b)同時可以達到知識共享 ，避免我們所有開發人員犯一些很常見，很普通低級的錯誤 ；
c)保證項目組人員的良好溝通 ，項目的代碼更容易維護
大家還有希望補充上
2．Code Review 很容易變得沒有意義或是流於形式，進入 Code Review 個人覺得以下幾點肯定得弄明確：
a) 我們是否理解了 Code Review 的概念和 Code Review 將做什麼，這點都不明白，做法可能就會是應付了事。
b) 我們的代碼是否已經正確的 build ， build 的目的使得代碼已經不存在基本語法錯誤 ，我們總不希望review人員浪費在檢查連編譯都通不過的代碼上吧。
c) 我們 Review 人員是否理解了代碼 ，做複查的人員需要對該代碼有一個基本的瞭解，其本功能是什麼，具體的業務是怎樣的，這樣才能採取針對性的檢查
3 .具體檢查點
1 完整性檢查
代碼是否完全實現了設計文檔中提出的功能需求
代碼中是否存在任何沒有定義或沒有引用到的變量、常數或數據類型
2一致性檢查
代碼的邏輯是否符合設計文檔
代碼中使用的格式、符號、結構等風格是否保持一致
3正確性檢查
代碼是否符合制定的標準
所有的變量都被正確定義和使用
所有的註釋都是準確的
4 可修改性檢查
代碼涉及到的常量是否易於修改 ( 如使用配置、定義爲類常量、使用專門的常量類等 )
5可預測性檢查
代碼是否具有定義良好的語法和語義
代碼是否無意中陷入了死循環
代碼是否是否避免了無窮遞歸
6健壯性檢查
代碼是否採取措施避免運行時錯誤（什麼空指針異常等，有很多是程序裏面處理了，但打印日誌時沒有判斷，不知道大家有沒有犯過這樣的錯誤喲）
7可理解性檢查
註釋是否足夠清晰的描述每個子程序 ，對於沒用的代碼註釋是否刪除
是否使用到不明確或不必要的複雜代碼，它們是否被清楚的註釋
使用一些統一的格式化技巧（如縮進、空白等）用來增強代碼的清晰度
是否在定義命名規則時採用了便於記憶，反映類型等方法
循環嵌套是否太長太深？
8可驗證性檢查
代碼中的實現技術是否便於測試
具體的楊帥同學也整理的很多很多，希望我們討論會上所有人員能達成一個共識，慢慢去完善！