1. 簡介
本文將介紹 Code Review的相關內容，包含為什麼要Code Review，以及Code Review主要review哪些部分的內容，之後講述如何才能形成一套比較好的Code Review規則和流程。後續講述了Code review中一些可以遵守的比較好的規則，最後講述瞭如何才能讓Code review流程跑起來。
本文為最近了解code review相關內容的總結，有問題/有建議可以在評論區幫忙指出，感謝！！！
2. 為什麼要code review
程式碼審查（Code Review）是現代軟體開發團隊中非常重要的一環，因為它可以帶來以下幾個方面的好處：
- 提高程式碼質量: 透過程式碼審查，開發團隊可以及時發現和修復程式碼中的問題，包括程式碼中的錯誤、潛在的安全漏洞、缺陷和效能問題等，從而提高程式碼的質量。
- 減少維護成本: 透過及時發現和修復問題，程式碼審查可以降低後續維護成本，因為修復問題的成本通常比在後期修復更低。
- 加強知識共享和團隊協作: 程式碼審查可以幫助團隊成員瞭解專案中其他成員的工作，從而促進知識共享和團隊協作，提高團隊整體的開發能力。
- 提高編碼規範和標準的遵守: 透過程式碼審查，可以促進團隊成員遵守編碼規範和標準，統一團隊的程式碼風格和程式碼質量要求，提高程式碼可讀性和可維護性。
- 促進開發者的技能提升和成長：程式碼審查可以幫助開發者瞭解專案中的技術細節和最佳實踐，從而促進開發者的技能提升和成長。
總之，程式碼審查可以幫助開發團隊提高程式碼質量和開發效率，降低維護成本，提高團隊協作和開發者技能，從而在軟體開發專案中發揮重要作用。
3.review哪些部分的內容呢
Code Review整個流程中，比較重要的一個節點，是對程式碼進行Review,然後指出程式碼中可能存在的問題。具體主要關注哪些程式碼問題，應該是每個團隊，在實踐中總結出適合自己的一套規範。這裡大概說明一些通用的Code Review可能需要關注的內容。
3.1 程式碼結構
- 程式碼的組織結構：程式碼應該按照一定的組織結構進行編寫，例如按照功能模組進行組織、按照層次結構進行組織等等。在審查程式碼結構時，應該關注程式碼的組織結構是否清晰、是否符合設計原則等方面。
- 模組化和可重用性：程式碼應該具有一定的模組化和可重用性，以便於程式碼的複用和維護。在審查程式碼結構時，應該關注程式碼是否具有可重用的模組、是否具有良好的介面設計等方面。
- 程式碼的層次結構：程式碼應該按照一定的層次結構進行編寫，例如分為介面層、業務邏輯層、資料訪問層等等。在審查程式碼結構時，應該關注程式碼的層次結構是否清晰、是否具有良好的模組劃分等方面。
3.2 程式碼邏輯
程式碼邏輯Review主要 包括條件分支、迴圈結構、異常處理、錯誤處理等方面的實現是否合理。
- 條件分支的檢查。 判斷條件是否覆蓋了所有可能的情況，是否有重複的判斷條件是否有不必要的巢狀。
- 迴圈結構的檢查。 檢查迴圈是否能夠正常終止，是否存在死迴圈，是否有更簡潔的迴圈方式。
- 異常處理的檢查。 是否對所有的錯誤進行正確的處理，是否提供合適的錯誤提示，是否能夠記錄錯誤日誌等。
3.3 程式碼的可讀性和可維護性
Review程式碼時，需要關注程式碼的可讀性和可維護性，包括程式碼的命名、註釋、縮排、程式碼段的長度、函式和方法的引數和返回值等方面。
- 命名應該清晰，簡潔，準確。程式碼中的變數、函式、類等命名應該具有清晰、簡潔、準確的特點。而不是簡單的字母或數字，且應該使用一致的命名方式，避免混淆。
- 註釋應該清晰、準確地描述程式碼的含義和作用。不應該重複程式碼，也不應該存在無用的註釋。註釋應該保持最新狀態，以便後續維護。
- 程式碼段的長度合適。：通常情況下，程式碼段的長度應該保持在一個比較合理的範圍內，以保證程式碼的可讀性。一些通用的建議是，每個函式或方法的長度應該控制在 100 行以內。
- 函式和方法的引數和返回值規範。 函式和方法的引數應該儘量少，入參和出參較多的情況下，可以考慮使用DTO來封裝。函式和方法的返回值應該儘可能明確，避免使用不必要的返回值或無意義的返回值。
- 避免使用魔法數字或魔法字串。
3.4 程式碼的可靠性
- 入參合法性檢查。 是否對輸入引數進行了合法性檢查，避免出現意外的輸入錯誤。
- 單元測試檢查。 是否進行了足夠的單元測試，並且能夠覆蓋各種邊界情況。
3.5 程式碼的可測試性
- 可測試檢查。 程式碼是否容易編寫測試用例，測試用例是否易於理解和維護。
- 單元覆蓋率檢查。 測試覆蓋率是否足夠，是否存在測試漏洞或者未考慮到的場景。
4. 制定cr的規則和流程是什麼呢
-
確定團隊的目標和需求
-
確定code review的規則和流程
- code review的時間安排，確定審查時機，以及時間安排
- 確定每次審查的程式碼量
- 確定審查的內容: 定義一份可用的checklist，確保審查者可以根據標準和指導進行 review。
- 確定用於進行 code review 的工具和環境
- 確定審查後需要進行修改的程式碼如何重新提交，如何跟蹤意見的處理過程。
-
開始實施
-
收集和分析資料
-
收集資料
-
收集問題型別和解決方式的資料，例如程式碼問題的型別、解決方式、處理時間等
- 記錄程式碼問題，如程式碼可讀性等內容
- 記錄問題的處理時間
- 對問題進行分類
-
收集code review的時間安排/程式碼量
- 收集每次code review的程式碼量
- 收集開始code review的時機
- 每次code review耗時，包含開發和reviewer的耗時
- 對專案釋出是否有影響
-
-
資料分析
-
根據資料記錄結果，獲取到code review經常出現的問題
- 新增程式碼靜態掃描規則，掃描出通用問題，減少code review問題
- 進行對應的分享，完成團隊內的知識共享
-
對code review的耗時進行分析，來改進流程
- 不同需求型別，每次code review的程式碼量是否合適
- code review開始的時機是否合適
- code review是否對專案釋出造成影響，在排期過程中，是否增加對code review的考慮
- 對reviewer的工作安排是否受到影響，有的話，如何解決
-
-
效果分析
- 程式碼質量的提升: 透過比較一段時間下來，發現的問題數量是否減少
-
-
規則和流程的最佳化
5. 可以遵守的比較好的code review的準則
- 每個提交的程式碼必須經過程式碼審查，以確保程式碼的質量和可維護性。
- 在程式碼審查之前，開發人員應該對自己的程式碼進行一次自審查，確保程式碼沒有明顯的錯誤和問題。
- 按照確定的規則進行審查：遵循指定的審查標準和流程，以確保一致性和準確性。
- 程式碼審查應該專注於發現程式碼中的問題和缺陷，而不是對開發人員進行評價或指責。
- 不要強制修改：審查人員應該將自己的建議視為建議而非命令，並與開發人員進行協商。
- 在程式碼審查中，開發人員應該積極參與討論，提出自己的觀點和想法，並接受他人的反饋和建議。
- 程式碼審查應該在合適的時間進行，以避免影響開發進度和專案交付時間。
- 程式碼審查結果應該被記錄下來，並及時修復和追蹤問題，確保問題得到解決和修復。
6. 如何讓code review跑起來
6.1 透過checklist來做code review
透過checkList來做code review似乎是一個比較好的方式，下面是開發者和reviewer的一個checkList的示例。
6.1.1 開發者的checklist
- 需求評審需要邀請reviewer參加
- 程式碼被審查前，自己先review一遍
- 需要提前和reviewer協調好程式碼review的時間
- 每次合併程式碼前都需要透過程式碼審查
- 程式碼有必要做單元測試的位置，已完成單元測試的覆蓋，單元測試已透過
6.1.2 reviewer的checkList
- 需要review的程式碼，需要參加需求評審/測試用例評審
- 需要預先留出code review的時間，排期時確定
- 程式碼review根據審查標準執行
- 每次合併程式碼是否透過程式碼審查
- 程式碼結構是否符合規範
- 程式碼邏輯是否存在問題
- 程式碼是否具有一定的可讀性
- 程式碼單元測試用例是否覆蓋充分
- 程式碼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更好地執行下去。