1. 簡介

本文將介紹 Code Review的相關內容，包含為什麼要Code Review，以及Code Review主要review哪些部分的內容，之後講述如何才能形成一套比較好的Code Review規則和流程。後續講述了Code review中一些可以遵守的比較好的規則，最後講述瞭如何才能讓Code review流程跑起來。

本文為最近了解code review相關內容的總結，有問題/有建議可以在評論區幫忙指出，感謝！！！

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更好地執行下去。