一、為什麼要review
1、提高代碼質量
這是代碼 Review 的初衷，也是代碼 Review 最直接的價值。Reviewers 根據各自的經驗，思考方式，看問題的角度給代碼提出各種可能的改進意見，從而形成更好的代碼以及產品質量。
我們知道產品問題越晚提出解決它的代價就越大，參與進去的人、要走的流程都會越來越多。代碼 Review 可以説是早期解決問題最有效的途徑之一了，在代碼 Review 中解決掉哪怕一個小問題都能避免後續一堆的麻煩事。
2、形成團隊統一的高質量標準
有效的代碼 Review 最終會在團隊範圍內建立起統一的質量標準，並且會隨着團隊成員的互相學習和促進形成更高的標準。參與者會在代碼 Review 的過程中基於具體問題從不同角度提出改進意見，並最終做出當前最佳的選擇並形成共識。隨着代碼 Review 的有效進行，團隊成員會有意識地關注代碼質量，從而形成越來越高的事實上的質量標準。
3、個人快速成長
通過有效的代碼 Review，Author 和 Reviewer 都將獲得成長，在 Review 過程中參與人就具體的問題展開深入的討論，無論是怎麼寫出整潔的代碼、怎麼更好地更全面地思考問題、怎麼最佳地解決問題，參與人都可以互相取長補短，互相提高。通過具體代碼實現進行的討論往往是最深入和有效的，代碼 Review 是開發者提高代碼能力最重要的途徑之一。
有的人認為代碼 Review 就是 Reviewer 幫助查找代碼中的 Bug，其實代碼 Review 不應該是一個單向的過程，而應該是個雙向交流的過程，Reviewer 幫助 Author 提出代碼改進意見的同時，也是向優秀的 Author 學習的過程。我們都知道提高代碼能力一個有效的途徑是閲讀優秀的項目代碼，但是閲讀項目代碼有着不小的難度，這也是大部分人沒有去執行的原因，而 Review 資深同事的代碼，我們在閲讀代碼的同時能夠直接進行有效的溝通，這是一個快速有效的學習途徑，尤其對開發經驗還不算豐富的開發者而言。
二、什麼時候發起 Review
2.1、場景
- 多人合作；
- 重要設計
2.2、時機
- Self-Review ： 提交代碼之前，自己審查一遍自己的代碼
- MR (Merge Request) ： 個人分支合併到公共分支（開發主分支）的時候；
三、Review 些什麼
- 變量、方法的命名（是否反映了它們的目的）
- 實現的邏輯是否已有現成的庫可以替代
- 是否有註釋（不好理解的地方需要有恰當的註釋）
- 代碼可讀性（代碼組織層次是否清晰、一致）
- 代碼健壯性（參數是否校驗、異常處理、代碼改動會不會影響其他功能）
- 代碼可擴展性
- 代碼編寫思路是否合理
四、如何快速完成codereview
1.不要刻意地去尋找代碼bug
有些代碼的邏輯是比較複雜的，如果是很容易就發現的缺陷，大多數情況下評審者自己在編碼過程就會發現，那麼剩下不容易發現的缺陷要發現也會花費較多的時間，這些問題可以交給測試人員去發現；
如果參與者刻意去找bug會造成顧此失彼，忽略更重要的東西；當然，有些bug你可能一眼就看出來了，那提出來就再好不過了。
2.不要帶着抨擊和質疑別人能力的心態去進行代碼評審
有時候參與者可能心情不好，或者感覺對方是新人就忍不住會抨擊對方的代碼，這樣會比較容易在模稜兩可的問題上浪費時間；
參與者可能認為A方法好，評審者可能認為B方法也不壞，這樣就會造成沒有必要的爭論而浪費時間。
3.不要在不確定的問題上爭來爭去
大家在討論的時候如果某些問題討論一段時間以後仍然沒有結論，或者需要第三方確認或者評審者不能馬上理解參與者提出的意見時，不要花太多時間討論這些問題；
把這些問題先記錄下來，等會議結束後評審者可以與參與者進行線下討論，同時將這些問題根據自己的理解進行解決，之後給大家一個反饋即可，這樣可以節省很多時間。
4.不要聽不進別人的意見
有些評審者比較固執，不願意接受大家的意見，會造成一些不必要的爭端和討論，浪費時間；
當然，有時候參與者的意見不見得是最好的，作為評審者將其作為一個參照的方向和視角，如果存在爭論，這些建議也可以做成會議記錄，評審者私下和建議提出者討論以後給大家一個結論。
5.參與者最好不要自己都沒想明白就提意見
如果參與者自己沒有想明白的事情就去提意見，那麼評審者反問的時候會浪費大家的時間；
參與者可以先將自己的想法大致記下來，自己想清楚了之後再提給評審者也是節省時間的辦法。
6.評審前最好先通過代碼靜態檢查工具檢測
一般規範性的問題都可以通過靜態檢測工具發現，藉助工具是最省事，也是效率最高的，還可以避免大家都評審時提出很多規範性問題，而遺漏了業務邏輯、設計合理性等問題。
