俗話說，沒有無緣無故的愛，也沒有無緣無故的恨，當然也沒有無緣無故的Code Review!
一、目的
- 保證團隊編碼風格一致
- 自己的代碼要給別人看，開發過程中需要潛意識的注意代碼規，以及邏輯嚴謹性。
- 保證項目質量，扼殺潛在風險
- 雖然功能完成后自己會自測，但難免會遺漏掉一些邊界點，或者受思維限制的一些點。
- 相互提升
- 多學習別人代碼，看高手是如何寫出嚴謹、簡潔、優美的代碼，和自己做對照，取齊精髓，去其糟粕！
- 便捷交叉維護
- 通過交叉Code Review過程，了解不同業務，方便后期交叉維護，無需花更多時間上手。
二、如何開展
- 結對
- 至少兩人為一小組
- review以及上線流程
- 所有項目master設置為Protected,並且設置allowed to push為No one，設置Merge checks為All discussions must be resolved，該分支作為deployment分支
- 開發時創建dev分支，並且同樣設置為Protected，allowed to push為No one，設置Merge checks為All discussions must be resolved，該分支作為development分支
- 個人分支最好以自己名字命名，需要review代碼時，提Merge Request到dev分支，代碼review人對代碼進行review，對不符合規范的代碼編輯comment，直到代碼沒有問題后標記comment為resolved（此時分支才會允許merge）
- dev分支經過測試沒問題上線之后，提MR到master分支，至此項目才真正上線完成
- 集體
- 每周周會集體review代碼，每次review核心代碼，預期每周集體review三位同學代碼
- 各自講解自己的模塊，復雜業務最好有流程圖
- git hooks – pre commit
- 新項目統一使用ESLint作為代碼規范檢測工具，每次Git commit會判斷代碼是否符合規范，只有符合規范的才能被提交
三、自測check list
之前都說在功能完成之后要進行自測，但具體從哪些方面切入沒有定義，之后大概可以從以下方面切入：
- 常規檢查
- 代碼是否能正常運行？
- 控制台是否有明顯的報錯？
- 代碼有沒有達到預期需求效果？
- 代碼邏輯是否簡單易懂？代碼書寫是否符合規范？是否盡可能組件化了？
- 有沒有重復造輪子？
- 去掉大段被注釋的代碼？（如果注釋代碼是可用的，那就先提交未刪除注釋的代碼到Git上，然后再提交刪除了注釋的代碼，以后能回滾就可以）
- 定時器是否隨生命周期消除？按鈕是否控制了單次點擊？
- 安全檢查
- 引入他人（公司內部或者其他外部機構）依賴包，是否存在不可用和版本升級導致功能不可用的風險？
- 所有請求是否都使用了https，包括圖片鏈接，對App應用嵌入的頁面，是否提供了https協議鏈接？
- 代碼注釋或者文案中是否包含了敏感詞匯？
- 文檔檢查
- 是否有符合規范的注釋？注釋是否描述准確？對方法參數或者名詞是否進行了解釋？
- 第三方庫使用是否有完善文檔？
- Readme文檔是否書寫規范？是否對項目有准確描述？
- 性能檢查
- 頁面加載是否超過了3s?超過3s的原因是什么？有沒有友好的提示？
- 代碼有沒有明顯影響性能的邏輯和計算？
- 組件層級是否可控？組件通信是否正常？頁面嵌套是否簡單？
四、評分標准
總分30分，24分以上是允許被merge到master的代碼，低於24分需要進行優化之后再提MR。
- 需求
- 9-10分：項目結構清晰，組件合理，代碼邏輯嚴謹，功能無遺漏
- 6-8分：無邏輯錯誤，功能無遺漏
- 0-5分：代碼邏輯錯誤，功能遺漏
- 代碼
- 9-10分：代碼簡潔，合理注釋，模塊獨立
- 6-8分：模塊中度耦合，代碼相對簡潔
-0-5分：模塊耦合度較高，代碼注釋不清晰，代碼書寫復雜，命名不規范
- 可讀性
- 9-10分：嚴格的代碼規范，代碼邏輯易理解，注釋清晰
- 6-8分：存在閱讀障礙的邏輯代碼，注釋模糊
- 0-5分：邏輯代碼混亂復雜，理解起來極其空難