一、CodeReview意義
- 提升團隊代碼設計水平
- 確保代碼設計和實現一致（前提需要有技術設計一環）
- 厘清業務邏輯細節，尤其是涉及多條業務線的情況
二、CodeReview問題
2.1 對于提交代碼的同學：
1、不清楚提交代碼 CR 的范圍？
2、不清楚需要給哪些人提交代碼 CR？
3、怎樣才能讓別人認真評審代碼？
2.2 對于參與評審代碼的同學：
1、不清楚需要 CR 代碼的業務上下文是怎樣的，不容易判斷代碼結構設計的合理性；
2、一下子提交幾千行代碼，哪些代碼是 CR 的重點內容，哪些不是；
三、代碼編寫規范
1. Java: 參考阿里編碼規范
2.代碼審核清單：
| 常規項 | 1 | 代碼能夠工作么？它有沒有實現預期的功能，邏輯是否正確等。 |
| 2 | 所有的代碼是否簡單易懂？ | |
| 3 | 代碼符合你所遵循的編程規范么？這通常包括大括號的位置，變量名和函數名，行的長度，縮進，格式和注釋。 | |
| 4 | 是否存在多余的或是重復的代碼？（應該抽取） | |
| 5 | 代碼是否盡可能的模塊化了？ | |
| 6 | 是否有可以被替換的全局變量？ | |
| 7 | 是否有被注釋掉的代碼？ | |
| 8 | 循環是否設置了長度和正確的終止條件？ | |
| 9 | 是否有可以被庫函數替代的代碼？ | |
| 10 | 是否有可以刪除的日志或調試代碼？ | |
| 安全 | 1 | 所有的數據輸入是否都進行了檢查（檢測正確的類型，長度，格式和范圍）并且進行了編碼？ |
| 2 | 在哪里使用了第三方工具，返回的錯誤是否被捕獲？ | |
| 3 | 輸出的值是否進行了檢查并且編碼？ | |
| 4 | 無效的參數值是否能夠處理？ | |
| 文檔 | 1 | 是否有注釋，并且描述了代碼的意圖？ |
| 2 | 所有的函數都有注釋嗎？ | |
| 3 | 對非常規行為和邊界情況處理是否有描述？ | |
| 4 | 優先使用工業化的第三方庫，衡量標準經過了大量的時間及完整文檔，還有專人或組織維護 | |
| 5 | 重要的數據結構和計量單位需要進行解釋 | |
| 6 | 是否有未完成的代碼？如果是的話，是不是應該移除，或者用合適的標記進行標記比如'TODO'？ |
四、代碼評審的方式
4.1 針對線上和線下評審的基本原則：
1、when(什么時候提交): 子任務開發完成, 由代碼提交者發起。
2、who（誰參與）:
a) 參與人：主講人，評審者，如果是線下評審需要有一名記錄者，以提升整體評審，問題記錄效率;
b) 提交給誰：
1、向團隊中經驗豐富的程序員提交 CR，以便于獲得更加高水平的代碼設計反饋；
2、大團隊劃分小組，小組內進行交叉CR
3、what（提交內容說明）: 在提交評審的時候，需要附上一定的說明，闡述清楚這些代碼主要實現邏輯（如果太大可以附上技術設計的鏈接和需求文檔鏈接），主要核心邏輯在哪些文件中，這樣 reviwer 在評審代碼的時候可以有的放矢。4、others (其他):
1、在迭代總結前：針對CR提出的問題需要進行總結，沉淀。 (問題沉淀模版，盡量減少大家總結時間)
4.2 線上評審
單人評審：gitlab上提交給reviewer進行在線評審
線上評審一般是主要的代碼 CR 方式，但是在提交評審的時候還是要遵循一定的原則，以便于提高代碼評審的效率。
每次提交 CR 的代碼不能超過200行，如果超過400行則需要轉線下評審（建議前期子任務盡量拆分的比較合理，如果每次評審的時候一下子推給別人幾千行代碼，估計對應的 reviwer 看都不想看，很難保證 review 的質量）；
4.3 線下評審
線下評審的基礎條件：涉及多個依賴模塊或者CR 代碼行超過400行
1、where: 由主講人預定線下會議（或者騰訊會議室），邀請必須參與的角色。
2、Time: 時間不超過2個小時
五、評估機制
|
|
指標名稱
|
計算公式
|
說明
|
|---|---|---|---|
| 1 | 單個有效評論成本 | CR投入工時/CR數 |
CR投入工時數據獲取可能不會太準確，尤其是線上評審部分 線下部分可以通過每次評審記錄表進行收集反饋，并上傳到Jira |
| 2 | 有效問題數 | 提交有效的CR評論數 | 如果確定有效的CR數？確定要解決的CR數屬于有效CR數？ |
| 3 | CR消耗工時 | CR結束時間-CR開始時間 | 代表投入成本 |
| 4 | 有效CR率 | 有效的CR評論數/總的CR評論數 | 總的CR評論數，可以通過api 接口獲取 |
| 5 | 大提交占比 | 單次提交超過200行代碼CR數/總CR數 | |
| 6 | 自評占比 | 自評CR數/總CR數 | |
| 7 | 人員參與度 | 參與CR的人數/總人數 | |
| 8 | 問題漏出率 | 1- CR召回的問題數/CR可召回的問題數 |
六、獎勵機制
- 每個迭代總結選出1-3名CR中提出高質量問題的同學。
- 每個迭代總結選出1-3名參與CR 次數最多的同學。
