Code Review（代碼審查）是軟件開發中的最佳實踐之一，可以有效提高整體代碼質量，及時發現代碼中可能存在的問題。包括像Google、微軟這些公司，Code Review都是基本要求，代碼合併之前必須要有人審查通過才行。
Code Review 好處
團隊知識共享的角度
一個開發團隊中，水平有高有低，每個人側重的領域也有不同。怎麼讓高水平的幫助新人成長？怎麼讓大家都對自己側重領域之外的知識保持瞭解？怎麼能有人離職後其他人能快速接手？這些都是團隊管理者關心的問題。
而代碼審查，就是一個很好的知識共享的方式。通過代碼審查，高手可以直接指出新手代碼中的問題，新手可以馬上從高手的反饋中學習到好的實踐，得到更快的成長；通過代碼審查，前端也可以去學習後端的代碼，做功能模塊A的可以去了解功能模塊B的。
可能有些高手覺得給新手代碼審查浪費時間，自己也沒收穫。其實不然，新人成長了，就可以更多的幫高手分擔繁重的任務；代碼審查中花時間，就少一些幫新人填坑擦屁股的時間；良好的溝通能力、發現問題的能力、幫助其他人成長，都是技術轉管理或技術上更上一層樓必不可少的能力，而通過代碼審查可以有效的去練習這些方面的能力。
代碼質量的角度
現實中的項目總是人手缺進度緊，所以被壓縮的往往就是自動化測試和代碼審查，結果影響代碼質量，欠下技術債務，最後還是要加倍償還。
也有人寄希望於開發後的人工測試，然而對於代碼質量來說，很多問題通過測試是測試不出來的，只能通過代碼審查。比如說代碼的可讀性可維護性，比如代碼的結構，比如一些特定條件才觸發的死循環、邏輯算法錯誤，還有一些安全上的漏洞也更容易通過代碼審查發現和預防。
也有人覺得自己水平高就不需要代碼審查了。對於高手來說，讓別人審查自己的代碼，可以讓其他人學習到好的實踐；在讓其他人審查的同時，在給別人說明自己代碼的時候，也等於自己對自己的代碼進行了一次審查。這其實就跟我們上學時做數學題一樣，真正能拿高分的往往是那些做完後還會認真檢查的。
團隊規範的角度
每個團隊都有自己的代碼規範，有自己的基於架構設計的開發規範，然而時間一長，就會發現代碼中出現很多不遵守代碼規範的情況，有很多繞過架構設計的代碼。比如難以理解和不規範的命名，比如三層架構裏面UI層繞過業務邏輯層直接調用數據訪問層代碼。
如果這些違反規範的代碼被糾正的晚了，後面再要修改就成本很高了，而且團隊的規範也會慢慢的形同虛設。
通過代碼審查，就可以及時的去發現和糾正這些問題，保證團隊規範的執行。
PR 人員交叉審覈
| 提交人 | 審查人 | Merge人 |
|---|---|---|
| 開發A | 開發B | 團隊lead |
| 開發B | 開發C | 團隊lead |
| 開發C | 開發D | 團隊lead |
| 開發D | 開發A | 團隊lead |
注意事項
先設計再編碼
有些人發現自己的代碼提交PR（Pull Request）後，會收到一堆的Code Review意見，必須要做大量的改動。這多半是因爲在開始做之前，沒有做好設計，做出來後才發現問題很多。
代碼在提交CODE REVIEW之前，要自己先 REVIEW 和測試一遍
做代碼審查的時候，有時候會發現一些非常明顯的問題，有些甚至自己都沒有測試過，就等着別人Code Review和測試幫助發現問題，這種依賴心理無論是對自己還是對團隊都是很不負責任的。
遇到緊急情況，來不及代碼審查怎麼辦？
雖然原則上，必須要Code Review才能合併，但有時候確實會存在一些緊急情況，比如說線上故障補丁，而又沒有其他人在線，那麼這種情況下，需要在Jira中，創建一個issue，用來後續跟蹤，確保後續補上Code Review，並對Code Review結果有後續的代碼更新。
Pull Request 的說明
- 任務完成才能提交PR。
- PR應該在一個工作日內被合併或者被拒絕。 PR在有嚴重問題（包括但不限於架構問題、安全問題、設計問題），太多問題，或者任務無效的情況下會被拒絕。
- 嚴禁一個PR裏面有多個任務，除非它們是緊密關聯的。
- PR提交之後只允許針對Review發現問題再次提交代碼，除非有充足的理由，嚴禁在同一個PR中再次提交其它任務的代碼。
提交PR時候有一個描述框，內容會自動根據Commit的message合併而成。 切記，如果一次提交的內容包含很多Commit，請不要使用自動生成的描述。 請用簡短但是足夠說明問題的語言（理想是控制在3句話之內）來描述：
你改動了什麼，解決了什麼問題，需要代碼審查的人留意那些影響比較大的改動。
特別需要留意，如果對基礎、公共的組件進行了改動，一定要另起一行特別說明。
審覈人員邀請原則：
參見: PR 人員交叉審覈列表
規範和制度
審查規則
不能爲了進度犧牲質量，無論進度有多麼緊迫，Code Review的過程都一定會做。
所有的問題一定會被提出，只是會根據進度的緊迫程度，以及問題的大小，改動成本，決定問題是現在解決，還是加一個TODO，並記錄在缺陷跟蹤管理系統內，以防日後遺忘。
多數情況下，我們都會要求立即解決，哪怕因此造成了發佈的推遲。
我們深知，其實多數情況下，現在不解決，日後不知道猴年馬月才能解決。
代碼規範
參照《代碼規範文檔》
獎懲措施
待完善