Mattias Karlsson

為什麼要做 Code Review#

你應該做 code review。因為它們能提升程式碼品質（increase code quality）並降低缺陷率（reduce defect rate）。但原因可能和你想的不同。

避免僵化的流程#

許多程式設計師過去可能有過不好的 code review 經驗，因此傾向排斥它們。有些組織要求所有程式碼在部署到生產環境之前都必須通過正式審查，通常由架構師或資深開發者執行。這種做法可以被稱為**「架構師審查一切」（architect reviews everything）**。

在大多數組織中，這種僵化和正式的流程是適得其反的：

• 被審查者會覺得自己像是被假釋委員會審判
• 審查者既要閱讀程式碼，又要跟上系統的所有細節，很快成為瓶頸
• 流程很快就會退化

Code Review 的真正目的#

Code review 的目的不只是糾正程式碼中的錯誤，而是要分享知識（share knowledge）和建立共同的程式設計準則。讓你的程式碼與其他程式設計師分享，能促進集體程式碼所有權（collective code ownership）。

讓隨機的團隊成員帶著其他人走讀程式碼（walk through the code）。與其尋找錯誤，你應該透過嘗試學習和理解來審查程式碼。

如何有效執行#

溫和且建設性#

在 code review 中要溫和。確保評論是建設性的，而非尖酸刻薄的（constructive, not caustic）。引入不同的**角色（roles）**來避免組織年資影響審查——例如一個人專注於文件、另一個專注於例外處理、第三個專注於功能。這有助於分散審查負擔。

定期舉辦#

每週安排固定的 code review day，花幾個小時進行審查會議：

• 用簡單的輪替方式輪換被審查者
• 記得在團隊成員之間輪換角色
• 讓新人參與 code review——他們可能經驗不足，但新鮮的大學知識能提供不同的視角
• 讓專家參與——他們的經驗和知識能更快、更準確地辨識出容易出錯的程式碼

善用工具#

如果團隊有工具自動檢查的程式碼風格規範（coding conventions），code review 會更順暢。這樣，程式碼格式就不會在審查會議上被討論。

讓 Code Review 有趣#

讓 code review 變得有趣可能是成功最重要的因素。審查的核心是人。如果審查會議痛苦或無聊，就很難激勵任何人。把它變成一個非正式的 code review（informal code review），主要目的是在團隊成員之間分享知識。留下尖酸刻薄的評論，帶上蛋糕或便當。