2. 為什么要code review

代碼審查（Code Review）是現代軟件開發團隊中非常重要的一環，因為它可以帶來以下幾個方面的好處：

1. 提高代碼質量: 通過代碼審查，開發團隊可以及時發現和修復代碼中的問題，包括代碼中的錯誤、潛在的安全漏洞、缺陷和性能問題等，從而提高代碼的質量。
2. 減少維護成本: 通過及時發現和修復問題，代碼審查可以降低后續維護成本，因為修復問題的成本通常比在后期修復更低。
3. 加強知識共享和團隊協作: 代碼審查可以幫助團隊成員了解項目中其他成員的工作，從而促進知識共享和團隊協作，提高團隊整體的開發能力。
4. 提高編碼規范和標準的遵守: 通過代碼審查，可以促進團隊成員遵守編碼規范和標準，統一團隊的代碼風格和代碼質量要求，提高代碼可讀性和可維護性。
5. 促進開發者的技能提升和成長：代碼審查可以幫助開發者了解項目中的技術細節和最佳實踐，從而促進開發者的技能提升和成長。

總之，代碼審查可以幫助開發團隊提高代碼質量和開發效率，降低維護成本，提高團隊協作和開發者技能，從而在軟件開發項目中發揮重要作用。

3.review哪些部分的內容呢

Code Review整個流程中，比較重要的一個節點，是對代碼進行Review,然后指出代碼中可能存在的問題。具體主要關注哪些代碼問題，應該是每個團隊，在實踐中總結出適合自己的一套規范。這里大概說明一些通用的Code Review可能需要關注的內容。

3.1 代碼結構

1. 代碼的組織結構：代碼應該按照一定的組織結構進行編寫，例如按照功能模塊進行組織、按照層次結構進行組織等等。在審查代碼結構時，應該關注代碼的組織結構是否清晰、是否符合設計原則等方面。
2. 模塊化和可重用性：代碼應該具有一定的模塊化和可重用性，以便于代碼的復用和維護。在審查代碼結構時，應該關注代碼是否具有可重用的模塊、是否具有良好的接口設計等方面。
3. 代碼的層次結構：代碼應該按照一定的層次結構進行編寫，例如分為界面層、業務邏輯層、數據訪問層等等。在審查代碼結構時，應該關注代碼的層次結構是否清晰、是否具有良好的模塊劃分等方面。

3.2 代碼邏輯

代碼邏輯Review主要 包括條件分支、循環結構、異常處理、錯誤處理等方面的實現是否合理。

1. 條件分支的檢查。 判斷條件是否覆蓋了所有可能的情況，是否有重復的判斷條件是否有不必要的嵌套。
2. 循環結構的檢查。 檢查循環是否能夠正常終止，是否存在死循環，是否有更簡潔的循環方式。
3. 異常處理的檢查。 是否對所有的錯誤進行正確的處理，是否提供合適的錯誤提示，是否能夠記錄錯誤日志等。

3.3 代碼的可讀性和可維護性

Review代碼時，需要關注代碼的可讀性和可維護性，包括代碼的命名、注釋、縮進、代碼段的長度、函數和方法的參數和返回值等方面。

1. 命名應該清晰，簡潔，準確。代碼中的變量、函數、類等命名應該具有清晰、簡潔、準確的特點。而不是簡單的字母或數字，且應該使用一致的命名方式，避免混淆。
2. 注釋應該清晰、準確地描述代碼的含義和作用。不應該重復代碼，也不應該存在無用的注釋。注釋應該保持最新狀態，以便后續維護。
3. 代碼段的長度合適。：通常情況下，代碼段的長度應該保持在一個比較合理的范圍內，以保證代碼的可讀性。一些通用的建議是，每個函數或方法的長度應該控制在 100 行以內。
4. 函數和方法的參數和返回值規范。 函數和方法的參數應該盡量少，入參和出參較多的情況下，可以考慮使用DTO來封裝。函數和方法的返回值應該盡可能明確，避免使用不必要的返回值或無意義的返回值。
5. 避免使用魔法數字或魔法字符串。

3.4 代碼的可靠性

1. 入參合法性檢查。 是否對輸入參數進行了合法性檢查，避免出現意外的輸入錯誤。
2. 單元測試檢查。 是否進行了足夠的單元測試，并且能夠覆蓋各種邊界情況。

3.5 代碼的可測試性

1. 可測試檢查。 代碼是否容易編寫測試用例，測試用例是否易于理解和維護。
2. 單元覆蓋率檢查。 測試覆蓋率是否足夠，是否存在測試漏洞或者未考慮到的場景。

4. 制定cr的規則和流程是什么呢

1. 確定團隊的目標和需求

2. 確定code review的規則和流程

   • code review的時間安排，確定審查時機，以及時間安排
   • 確定每次審查的代碼量
   • 確定審查的內容: 定義一份可用的checklist，確保審查者可以根據標準和指導進行 review。
   • 確定用于進行 code review 的工具和環境
   • 確定審查后需要進行修改的代碼如何重新提交，如何跟蹤意見的處理過程。

3. 開始實施

4. 收集和分析數據

   • 收集數據

     • 收集問題類型和解決方式的數據，例如代碼問題的類型、解決方式、處理時間等

       1. 記錄代碼問題，如代碼可讀性等內容
       2. 記錄問題的處理時間
       3. 對問題進行分類

     • 收集code review的時間安排/代碼量

       1. 收集每次code review的代碼量
       2. 收集開始code review的時機
       3. 每次code review耗時，包含開發和reviewer的耗時
       4. 對項目發布是否有影響

   • 數據分析

     • 根據數據記錄結果，獲取到code review經常出現的問題

       1. 添加代碼靜態掃描規則，掃描出通用問題，減少code review問題
       2. 進行對應的分享，完成團隊內的知識共享

     • 對code review的耗時進行分析，來改進流程

       1. 不同需求類型，每次code review的代碼量是否合適
       2. code review開始的時機是否合適
       3. code review是否對項目發布造成影響，在排期過程中，是否增加對code review的考慮
       4. 對reviewer的工作安排是否受到影響，有的話，如何解決

   • 效果分析

     1. 代碼質量的提升: 通過比較一段時間下來，發現的問題數量是否減少

5. 規則和流程的優化

5. 可以遵守的比較好的code review的準則

1. 每個提交的代碼必須經過代碼審查，以確保代碼的質量和可維護性。
2. 在代碼審查之前，開發人員應該對自己的代碼進行一次自審查，確保代碼沒有明顯的錯誤和問題。
3. 按照確定的規則進行審查：遵循指定的審查標準和流程，以確保一致性和準確性。
4. 代碼審查應該專注于發現代碼中的問題和缺陷，而不是對開發人員進行評價或指責。
5. 不要強制修改：審查人員應該將自己的建議視為建議而非命令，并與開發人員進行協商。
6. 在代碼審查中，開發人員應該積極參與討論，提出自己的觀點和想法，并接受他人的反饋和建議。
7. 代碼審查應該在合適的時間進行，以避免影響開發進度和項目交付時間。
8. 代碼審查結果應該被記錄下來，并及時修復和追蹤問題，確保問題得到解決和修復。

6. 如何讓code review跑起來

6.1 通過checklist來做code review

通過checkList來做code review似乎是一個比較好的方式，下面是開發者和reviewer的一個checkList的示例。

6.1.1 開發者的checklist

1. 需求評審需要邀請reviewer參加
2. 代碼被審查前，自己先review一遍
3. 需要提前和reviewer協調好代碼review的時間
4. 每次合并代碼前都需要通過代碼審查
5. 代碼有必要做單元測試的位置，已完成單元測試的覆蓋，單元測試已通過

6.1.2 reviewer的checkList

1. 需要review的代碼，需要參加需求評審/測試用例評審
2. 需要預先留出code review的時間，排期時確定
3. 代碼review根據審查標準執行
   • 每次合并代碼是否通過代碼審查
   • 代碼結構是否符合規范
   • 代碼邏輯是否存在問題
   • 代碼是否具有一定的可讀性
   • 代碼單元測試用例是否覆蓋充分
4. 代碼review需要記錄問題類型，方便統計數據

6.2 限制 Code Review 時間

限制單次code review的時間，能夠避免待review的代碼量過多，如果一次待review的代碼量過多，此時整個流程很容易流于形式。因此，這里可以根據不同團隊的實際情況，定義好單次code review的耗時，限制在一個時間范圍內。

6.3 代碼靜態掃描規則的建立

對于一些常見的代碼review的問題，可以制定代碼掃描規則，在code review之前，先執行一次代碼掃描，識別出其中比較常見的問題，減少代碼review的時間。

這樣對于也減輕了reviewer的負擔，也利于開發者自行發現問題，自行解決，避免時間的浪費。

6.4 學習和分享

團隊中的成員可以定期分享 Code Review 的經驗和技巧，以便更好地提高審查的效率和質量。
有這樣一個分享，那么code review這個過程可以作為一個輸入，能夠增加大家code review的參與度。

6.5 反饋和改進

code review的流程，在執行過程中，大概率會發現其中并不合理的地方，或者有待改進的地方，此時應該每隔1個月/2個月，來回顧整個流程，發現其中不合理的地方，讓code review更好得進行下去。

同時，在code review過程中，也有收集一些code review的數據，可以對其進行分析，發現其中不合理的地方，針對不合理的地方進行改進。

7. 建立code review的流程的實踐過程

7.1 確定團隊目標

首先，團隊建立code reviwe的目標和需求，為什么要code review,有目標了，后續才能評估code review是否達到了目的。

7.2 時間節點的確定

首先需要確定code review的時間節點的安排。是開發完成后，提測前開始code review還是其他時間節點呢。code review的時間安排是否包含到項目排期中。

reviewer是否得提前知會，在何時知會? 其是否要參加需求評審以及測試用例評審等項目相關需求的評審會? 以及reviewer在code review過程的所耗工時要怎么統計呢，是不是在項目排期時，也需要考慮到code review的耗時，然后耗時大致的排期，是否設定為開發時間的10%,還是其他，是否先執行，后續再根據實際情況調整呢?

7.3 review平臺以及review形式的確定

上面code review的時間安排已經確定好了，之后便需要開始code review,這里需要團隊內確定code review的工具，是使用開源工具，如reviewBoard,亦或者是直接gitlab平臺提交mr的時候順便review呢,這個也需要確定。

當平臺確定好之后，我們需要確定review的形式，是開發和reviewer一起review,reviwer一邊看一遍提問，亦或者是reviewer先整體看一遍，然后有疑問再提出，然后開發再當面說明，或者是其他形式，這個也是需要確定的。

7.4 review代碼量的確定

之后比較重要的點，便是每次review的代碼量的問題,我們可以想象，如果每次需要review的幾千行的代碼，此時往往review便會流于形式，其實并不會起到太大的作用。這里應該由團隊內部協商好code review的形式，是單次少量，多次review; 還是項目開發完成之后，再整體review; 或者是兩者的結合,一些項目整體開發完成之后再review,一些項目采取單次少量，多次review的形式，亦或者是其他。

7.5 review內容的確定

接著，就要開始代碼review,這里就需要確定review主要review哪些內容，這個示例可以參考第三點所說的，review哪些部分的內容，不過還是需要團隊自行確定。不過這里有個前置依賴，團隊需要有一套統一的代碼規范，如命名規范等。這里假設已經確定review的內容包含代碼的可讀性，如果沒有一套統一的規范，review流程是比較難執行下去的。

7.6 數據收集方式確定

到這里，我們可以算是完成了一次code review的流程，但是一個流程如果只有執行，沒有回顧，那是不太合適的，所以對于code review的流程是需要定時回顧的。當進行回顧時，需要有數據來做支撐的，才能識別出整體流程是否存在不合理的地方，那數據從哪里來呢?那只能從每次代碼review的過程中獲取。

所以，這里也需要定義每次review流程中，需要記錄下來一些內容，方便后續回顧，具體記錄的內容，可以參考第四點制定cr的規則和流程是什么呢 中第四點的內容，然后數據記錄的方式也可以統一一下，比如使用飛書文檔或者多維表格，亦或者是其他形式來存儲。方便后續回顧使用。

7.7 code review如何更好得執行

當上面的內容都確定好之后，在我看來，一個code review的流程其實就已經完成了，這個時候便可以考慮如何讓code review整個流程跑得更順暢，這里可以參考第六點如何讓code review跑起來中的內容，比如使用checkList來減輕心智負擔，其次可以建立靜態掃描規則集，能夠減少code review的工作量等。

7.8 定時回顧

然后再定時回顧整個code review的流程，發現其中不合理的地方，再對其進行改進。

8. 總結

該文檔是一篇關于Code Review的輸出，介紹了Code Review的規則和流程需要包含的內容，以及具體需要Review的內容。此外，還描述了一些在Review過程中需要遵守的原則，如尊重，建議等，以保持Review的積極性和有效性。
最后，列舉了一些方式，如定期進行Review、使用靜態代碼掃描工具、checklist來進行code review，進行學習和分享，能夠讓Code Review更好地執行下去。