Google 的軟體工程之道 (5) — 程式碼審查 ( Code Review)

https://innovecs.com/blog/building-software-development-teams/

此系列為 【 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

1. Greenfield (綠地)，也就是全新功能，要頻估是否此變更能經得起時間的考驗。但不是一個提供 API 文件修改或以決定的設計的好時機。
2. Improvement，偏向於優化，也就是 API 更改或效能優化，甚至刪除也可以是其中一種選擇。這部分的審核非常仰賴成熟 CI 機制來做到自動保護的動作
3. Bug，要小心一個改動同時修復多個問題，可能增加 rollback 的困難度，同時也建議新增對應的單元測試
4. Refactor，大規模的修改也是這種類型，一些透過自動化產生的變更，可能屬於這塊 ( 套件依賴更新…etc)

Google 標準的 Code Review 流程

1. 作者準備 commit，並說明變動的相關資訊，以 snapshot 形式存在
2. 作者經過自動 review 工具與自我審查後，將 snapshot 寄送給 reviewers
3. Reviewers 留下評論，主要有必須解決的問題與建議兩種
4. 作者根據評論進行修改，並再通知審查者
5. 使用 LGTM ( Looks good to me) 標記此變更通過審查
6. 作者 commit 程式碼到 codebase 中

Google 的 Code Review 面向

• 正確性
• 可維護性
• 技術債程度
• 可讀性，尤其是公司認可的可讀性審查者，包括風格的適切性
• Code Owner ( 領域專家)

關於 Code Owner

• 隨著公司程式碼規模變大，不可能一個人理解所有的程式碼，因此最好能透過特定路徑或資料夾來拆分擁有者
• 透過明確的 owner 文件，能讓問題很快地找到適合解決的人
• 在 Github 中就有 Code Owner 的開源機制可以運用，推薦參考:

About code owners - GitHub Docs

如果喜歡這個系列的話，歡迎將此連結加入你的最愛:

【 Google 的軟體工程之道 】全系列 https://medium.com/@johnliutw/list/da301cc31b15