Google 的軟體工程之道 (5) — 程式碼審查 ( Code Review)
Published in
4 min readApr 16, 2023
此系列為 【 Google 的軟體工程之道 】一書的書摘與點評,期待用最精要的文字,帶來豐富的內容分享。預計 2~3 周左右會有一篇更新,歡迎追蹤支持!
【 Google 的軟體工程之道 】全系列: https://medium.com/@johnliutw/list/da301cc31b15
核心理念
- 新增程式碼是一種責任,任何新的程式碼都要再三思考,是否已有存在的解決方案
Code Review 的益處
- 確保程式碼正確性,越早發現,修復成本越低。但要注意審查成本不能過高,否則會很難達到此效果。
- 確保其他工程師能夠流暢理解不同人開發的程式碼,由於被讀的次數遠大於被寫的次數,因此這是很重要取得可讀性回饋的環節
- 強化整個程式碼的風格一致性,相當於程式碼的健康程度
- 從心理上促進團隊對程式碼的所有權意識,確保程式碼不是“作者”的,而是整體組織的,但也要留意人類不喜被批判的天性
- 讓新發現的知識易於被分享,尤其是工程師喜歡閱讀審查評論勝於 Email。
- 提供 Code Review 本身的歷史記錄
Code Review Best Practice
- 保持禮貌和專業,除非是正確性或規則性的問題,否則主觀的議題應偏向接受作者的意見,並要盡可能的即時做出回饋 ( 1 個工作天內)
- 盡可能縮小審查的範疇,同時能降低可能的錯誤來源數量,但這並不是必要狀況。可以以 200 行作為一個參考基準,也能幫助審查者降低審查時間
- 在變更描述中的內容,應該要陳述會變更的類別 ( feature, bug, refactor…etc),並要能詳述說明內容摘要 ( “Bug 修復”,這樣的描述沒有任何意義 )
- 盡可能減少 reviewers,越新增的 reviewers 所帶來的價值是遞減的
- 盡可能自動化,例如可以針對錯字、security issue、ticket status、Unit Test 做自動化檢查設定
Code Review Types
- Greenfield (綠地),也就是全新功能,要頻估是否此變更能經得起時間的考驗。但不是一個提供 API 文件修改或以決定的設計的好時機。
- Improvement,偏向於優化,也就是 API 更改或效能優化,甚至刪除也可以是其中一種選擇。這部分的審核非常仰賴成熟 CI 機制來做到自動保護的動作
- Bug,要小心一個改動同時修復多個問題,可能增加 rollback 的困難度,同時也建議新增對應的單元測試
- Refactor,大規模的修改也是這種類型,一些透過自動化產生的變更,可能屬於這塊 ( 套件依賴更新…etc)
Google 標準的 Code Review 流程
- 作者準備 commit,並說明變動的相關資訊,以 snapshot 形式存在
- 作者經過自動 review 工具與自我審查後,將 snapshot 寄送給 reviewers
- Reviewers 留下評論,主要有必須解決的問題與建議兩種
- 作者根據評論進行修改,並再通知審查者
- 使用 LGTM ( Looks good to me) 標記此變更通過審查
- 作者 commit 程式碼到 codebase 中
Google 的 Code Review 面向
- 正確性
- 可維護性
- 技術債程度
- 可讀性,尤其是公司認可的可讀性審查者,包括風格的適切性
- Code Owner ( 領域專家)
關於 Code Owner
- 隨著公司程式碼規模變大,不可能一個人理解所有的程式碼,因此最好能透過特定路徑或資料夾來拆分擁有者
- 透過明確的 owner 文件,能讓問題很快地找到適合解決的人
- 在 Github 中就有 Code Owner 的開源機制可以運用,推薦參考:
如果喜歡這個系列的話,歡迎將此連結加入你的最愛:
【 Google 的軟體工程之道 】全系列 https://medium.com/@johnliutw/list/da301cc31b15