Code Review 如果兼顧 Code Quality 能為團隊帶來甚麼

Code Review 的目的不只是在當下「功能能不能跑」，而是要在不顯著拖慢交付的前提下，降低 Bug 風險、降低 未來變更成本，並讓程式碼能被「非原作者」安全維護。

為了避免 Code Review 變成個人偏好爭論，這裡的 Code Quality 指的是：會影響未來修改速度、修改風險與可測試性的因素（可維護性風險），而不是純粹的美觀或風格。

修改成本才是真正的長期成本

1) 敏捷不是一次性交付，而是產品長期維護

在產品型開發下，程式碼會持續新增與調整，不會在功能完成後停止變動。

因此，程式碼是否容易理解 會直接影響後續修改的速度與品質。

  • 當結構與意圖不清楚，理解成本會隨時間累積
  • 開發者需要花更多時間釐清既有邏輯，導致修改變慢、風險升高
  • 最終讓敏捷強調的「快速回應變化」難以落實

換句話說：交付速度的瓶頸，長期會落在變更與維護，而不是第一次寫出來的速度。

2) 維護成本來自「修改頻率 × 理解成本」

在敏捷下，真正的成本不是第一次寫的成本，而是：

維護成本 ≈ 修改次數 ×（理解成本 + 修改成本 + 回歸風險）

當一段程式越難理解，每一次修改就越慢；越慢就越不敢動，越容易用「暫時方案」堆疊，技術債自然增加。

因此，Code Review 若能在早期降低理解成本，其實是在為未來每一次修改節省時間、降低風險。

3) 提升修改信心（Change Confidence）

可讀性高、結構清楚、設計合理的程式碼，通常也更容易撰寫測試； 而測試能在修改時保護原始需求，讓工程師更有信心調整行為。

相反地，當程式難以理解時，即使需求很清楚，也容易因為無法確定影響範圍而保守處理，最後技術債累積、開發效率下降。

例 1：不敢改 → 加 if 仍導致 Bug

需求其實不複雜，但因為原本邏輯難懂，不敢直接改，只好再加一層 if 先避開。 短期看起來安全，但因為影響範圍不明，即使只是多加 if 也可能產生預期外 bug。

例 2：因為不懂 → 複製一份邏輯 不確定原本程式在做什麼，就複製一份類似邏輯再改。 短期看比較保險，但長期會留下兩份行為接近卻不完全一致的 code，之後維護成本與風險倍增。

這兩種狀況的共同原因不是能力問題，而是程式碼缺乏可預測性； Code Review 對可讀性/結構的要求，是在提高可預測性與修改信心。

維護成本不應與特定人員綁定

1) 系統維護不應依賴原作者或少數人

若一段程式碼只有原作者或少數資深能快速理解，代表維護成本已與特定人員綁定（bus factor 風險）。 一旦原作者不在，修改速度與風險就會明顯上升。

這不是誰比較強，而是程式碼本身的可讀性與結構，讓知識無法自然被團隊吸收。

2) Code Review 是分散理解的關鍵時點

在目前流程中，Code Review 幾乎是唯一一個「非原作者」會完整閱讀並嘗試理解程式碼的時候。 如果 reviewer 在這階段就覺得難以理解，代表未來換人接手時，理解成本只會更高、風險也更大。

因此，CR 不只是確認功能是否正確，還是在提前暴露：

「這段 code 是否能被其他人安全維護？」