檢查設計的合理性

設計的合理性可以從以下幾個方面考慮：

1、代碼的設計是否符合詳細設計的要求：首先，我們要觀察代碼是否符合設計的需求，如果存在代碼和詳細設計有出入的地方需要問詢為什么要變動，因為這些變動有可能是出于開發者在真正設計代碼時候的深入考慮，或者是由于一時大意出現偏差。

2、業務邏輯是否錯誤：業務流程是否按照詳細設計的流程走；是否有異常處理機制等等

3、關注擴展性：我們的業務在不斷的發展，每一個項目的設計都會影響后續業務的拓展，一個好的設計應該考慮到后續業務的發展，而盡量避免定制化的設計。

4、關注使用到的數據結構、設計模式、代碼的性能（效率），出于對系統性能的考量，我們要關注編寫代碼對系統的開銷，包括使用的算法是否合理，以及對某些比較耗時的操作比如數據庫的操作要加以關注。

檢查代碼的可讀性

如果代碼的可讀性強，那么維護起來也就方便很多；一個好的代碼規范和編碼風格會節省大家對代碼的理解時間，減少維護成本雖然我們有代一些編程規范的價差工具，但是有些東西還是檢查不出來而靠大家去規范的。

1、代碼注釋

2、命名規范性

3、是否存在重復代碼

4、邏輯是否繁瑣

不要刻意尋找代碼的bug：有些代碼的邏輯是比較復雜的，如果是很容易發現的錯誤，評審者在編碼的過程大多數都會發現，那么剩下的不容易發現的錯誤應該交給測試人員去發現；如果參與者刻意去找Bug將會是顧此失彼，忽略更重要的東西；當然如果有些Bug你一樣就看到了就再好不過了。

不要按照自己的編程風格去評論別人的代碼：有些人可能比較自負，會根據自己熟悉的編碼語言或者編碼風格去評論別人的代碼；只要代碼是符合命名要求也符合設計要求就可以了，不過還是那就話，如果編碼者的確錯誤明顯當然可以提出帶大家討論一下。

不要帶著質疑別人能力的心態進行代碼評審：有些時候參與者可能是由于心情不好，或者感覺對方是新人就會可以的去抨擊別人的代碼，這樣會帶來一個問題，就是在模棱兩可的問題上浪費時間；參與者可能認為A方法好，評審者可能認為B方法也不壞，這樣就會造成沒有必要的爭論而浪費時間。

不要聽不進別人的意見：有些評審者比較自負，不愿意接受大家的意見，而造成不必要的爭端和討論；當然有的時候參與者的意見不見得是最好的，但是也可以是一個參照的方向，如果存在爭論，這些建議也可以做成會議記錄，評審者私下和建議提出者討論以后給大家一個結論。

參與者最好不要自己都沒想明白就提意見：如果參與者自己沒有想明白的事情就去提意見，那么評審者反問的時候會浪費大家的時間；參與者可以先將自己的想法大致記下來，在有空閑的時間想清楚了在提給評審者也是節省時間的辦法。

發現代碼的正確性：Code Review的用意是在代碼提交前找到其中的問題——你要發現它的正確。在Code Review中最常犯的錯誤（幾乎每個新手都會犯的錯誤）是審查者根據自己的編程習慣來評判別人的代碼。

Code Review更重要的是在分享和學習：Code Review最重要的是講解者分享業務流程和設計思路，參與者通過這些講解獲得這些信息，使得更多人理解這個系統，提升團隊整體水平，使得團隊維護代碼的能力提升。

高效高質的完成Code Review：我們不能為了應付，匆匆忙忙地進行一次Code Review，效果也是很重要的，如果不能保證Code Review實現目的，那么評審便是徒勞的。