- 前言
- 一、為什麼要做
- 二、有哪些好處
- 三、具體怎麼做
- 3.1評審條件
- 3.2評審重點
- 3.3評審形式
- 四、還可以怎麼做
- 4.1提出亮點
- 4.2輪流評審
- 4.2文件沉澱
- 五、文章小結
前言
你是否曾寫過一個很簡單的需求或者最佳化？而且你認為不需要審查，就可以直接合併到主分支。可能過了幾天或者幾周，你突然意識到你犯了一個明顯的或是不應該的錯誤。如果有其他人來審查程式碼，那這個問題可能就會被發現並及時處理。
CodeReview（程式碼評審）是一種用來確認方案設計和程式碼實現的質量保證機制，透過這個機制我們可以對程式碼、測試過程和註釋進行檢查，主要用來在軟體工程開發過程中改進程式碼質量。
可能大家會認為必須是領域內的專家或者資深工程師才能審查別人的程式碼，但是以筆者的經驗來看：其實並不是這樣的，評審人並不需要完全理解該專案的業務需求或者有多麼豐富的編碼經驗，只需要為本次程式碼評審提供新的、合理的、符合規範的視角。
下面筆者以自己的實際經驗來和大家分享一下，如何做好專案開發中的程式碼評審。
一、為什麼要做
程式碼評審首要目的就是為我們帶來一雙新的眼睛，從新的視角去看待那些潛在的問題。
以筆者目前所在的團隊來說，程式碼審查是開發過程中的關鍵步驟。透過儘早發現和解決問題，不僅能提高產品的質量，還能確保程式碼的一致性和可靠性，它還能讓開發團隊對產品的構建方式與產品所需要的標準達成一致。
因此，儘管程式碼評審可能在當前會比較費時費力，但隨著時間的推移，程式碼審查發揮的作用會越來越明顯。
二、有哪些好處
CodeReview 習慣的保持、積極參加團隊的 CodeReview，起碼能有以下幾點顯而易見的好處：
- 提升程式碼質量：程式碼評審可以幫助團隊成員發現潛在的缺陷、漏洞和效能問題，從而確保程式碼的穩定性和可維護性。透過評審，團隊成員可以互相學習，借鑑他人的優秀實踐，提高自己的編碼水平。
- 促進團隊協作：程式碼評審是一種提高團隊協作的方式，有助於團隊成員更好地瞭解彼此的工作內容和進度。在評審過程中，團隊成員可以互相交流、分享經驗，從而提高整個團隊的技術水平和解決問題的能力。
- 保證專案進度：程式碼評審可以及時發現和解決問題，避免在專案後期出現嚴重的技術債務。透過評審可以確保專案按計劃推進，提高開發效率。
- 培養團隊文化：程式碼評審有助於培養團隊的學習氛圍和進取精神。透過互相評審，團隊成員可以共同進步，形成積極向上的團隊文化。
三、具體怎麼做
3.1評審條件
- 前置條件：程式碼已透過 Alibaba Java Coding Guidelines(idea 外掛）的程式碼檢查；
- 大型專案：增加/修改超過 10 個檔案或超過 200 行程式碼的，需組織 CodeReview 會議，邀請相關同事及高階/資深開發同事參與；
- 小型專案：小需求修改如：少於 10 個檔案變更或少於 100 行程式碼的），至少需要 1~2 位同事幫忙 Review 並提出修改建議；
- 重點邏輯：建議邀請負責過該專案的同事共同 Review 一下，或者在開發的時候結對 Review。
3.2評審重點
- 完整性檢查：功能點、業務日誌、異常日誌等
- 一致性檢查：程式碼邏輯是否符合設計文件，程式碼風格是否統一等
- 正確性檢查：技術選型、註釋是否準確、變數的定義和使用等
- 可修改性檢查：如魔法值 123，使用專門的常量類或列舉等
- 可預測性檢查：死迴圈、無窮遞迴、陣列越界、空指標等
- 可理解性檢查：命名規則、註釋是否清晰、git 提交記錄描述等
- 邏輯性檢查：實現不過於複雜、程式碼拆分、可讀性、擴充套件性等
- 安全性檢查：包括防止注入攻擊、保護敏感資料、介面鑑權等
3.3評審形式
-
會議評審：將相關評審人員集中在一起，透過會議討論的方式進行程式碼評審，如無其它緊急情況，建議每月一次。此方法適用於中小型團隊或重要的程式碼更改。
如：
- 部門負責人組織評審會議，時間可以固定在當月的某一天，大約 15-20 分鐘；
- 地點可以選擇一個小的會議室，大約能容納 10-15 個人，需要有投影裝置；
- 與會人員可以是部門的整個後端團隊，擬定一個主評審人，大家都可以參與討論
-
隨機抽查：隨機選擇一部分程式碼進行評審，以驗證程式碼的質量和規範性。這種方法可以作為團隊日常工作的一部分。
-
工具支援：使用程式碼評審工具來自動化一些評審過程，例如程式碼靜態分析工具和程式碼規範檢查工具。這些工具能夠提供一些有關程式碼質量的重要指標，並幫助識別潛在的問題。
四、還可以怎麼做
4.1提出亮點
- 不僅要提出需要改進的地方，也要提出本次程式碼評審的亮點，具體可以從以下幾點入手：
- 效能最佳化：是否有對效能有最佳化，合理使用資料庫連線、時/空間複雜度、記憶體操作等；
- 設計模式：是否有抽象出通用的設計模式，顯著提高模組的複用率、擴充套件性等；
- 工具/外掛：是否有能提高效率的工具類，包括可以釋出的外掛以及自定義註解等。
4.2輪流評審
- 需要注意的是，主評審人應該是團隊裡的每一位成員，而不是僅由部門領導或資深工程師來擔任，理由如下:
- 集思廣益：每次的程式碼評審最重要的是引入新的視角來看待潛在的問題，每個人都會有自己的視角，這樣有助於團隊統一認識；
- 機會平等：年輕的工程師們雖然可能經驗不足，但幹勁兒可能比較足，如果能借此機會得到一些鍛鍊，那麼對團隊來說會是一件好事。
4.2文件沉澱
- 有了以上的種種具體做法，那麼最終還是要把結果文件化、持久化的，具體可以：
- 評審會議前由主評審基於模板去擬好一篇文件在會上展示，包括給出程式碼片段、改進建議、提出亮點等，方便會上大家及時討論補充；
- 會後可以上傳到團隊的文件空間或者工作集當中，方便團隊成員隨時學習、回顧。
五、文章小結
關於如何做好專案開發中的 CodeReview（程式碼評審）就和大家分享到這裡，希望能對大家有一些幫助。
寫在最後，文章如有不足和錯誤，還請大家指正。或者你有其它想說的，也歡迎大家在評論區交流！