[工程分享] Code Review 不是只挑錯

前言

剛開始接觸 Code Review 時，很容易把它想成「找別人錯誤」的流程。

但實際工作一段時間後，我覺得 Code Review 更像是團隊同步理解的過程。

它不只是為了找 bug，也是在確認這段程式碼是否容易維護、是否符合團隊習慣，以及未來的人能不能接得下去。

先理解需求再看程式碼

Review 前，我會先看這次變更想解決什麼問題。

如果沒有先理解需求，很容易只針對語法或個人偏好留言。

比較好的順序是：

• 這個 PR 想解決什麼問題？
• 使用者或系統行為會怎麼改變？
• 有沒有影響既有流程？
• 測試是否覆蓋到主要情境？

先知道目的，再看實作，才比較能判斷這段程式碼是否合理。

不要只看能不能跑

程式能跑只是基本。

Code Review 還可以多看幾件事：

• 命名是否清楚？
• 是否有重複邏輯？
• 錯誤處理是否完整？
• 邊界情境是否有考慮？
• 是否和既有架構一致？
• 有沒有不必要的複雜度？

好的 Review 不是挑剔，而是幫這段程式碼在未來少出一點問題。

留言要具體

我覺得 Code Review 留言最怕太抽象。

例如：

這樣不好

這種留言對作者幫助不大。

比較好的寫法是：

這裡如果 user 為 null，後面呼叫 user.Name 會拋出 NullReferenceException。
建議在進入主要流程前先做 null check。

這樣作者會知道：

• 問題在哪裡
• 可能造成什麼後果
• 可以怎麼調整

區分問題和偏好

不是每個留言都一定是 blocker。

有些是真正的問題，例如：

• 會造成 bug
• 會破壞既有功能
• 有資安風險
• 缺少必要測試

有些則比較偏個人習慣，例如：

• 命名風格
• 程式排版
• 寫法偏好

如果是偏好，可以用比較柔和的方式提出：

這裡也許可以改成 early return，讀起來會再直一點。

這樣比較不會讓 Review 變成互相消耗。

結語

Code Review 的目標不是證明誰比較厲害，而是讓團隊一起把品質拉起來。

我會提醒自己：

• 先理解需求，再看實作。
• 留言要具體，不要只丟感覺。
• 區分真正問題和個人偏好。
• 語氣保持合作，而不是審判。

好的 Review 會讓人更願意改善程式碼，而不是更害怕送 PR。