Code Review 程式碼審查

讓其他人檢查程式碼是否正確、可維護、有沒有風險。

先用一句話理解

讓其他人檢查程式碼是否正確、可維護、有沒有風險。

打個比方

像出貨前的品管，不只看能不能動，也看會不會容易壞。

什麼時候會遇到

多人協作、重要功能、付款、權限、資料處理修改時。

再往深一點看

Code review 是在 PR 合併前，由一位或多位團隊成員仔細閱讀程式碼改動、提出問題或建議的過程。它的目標不只是找 bug，還包括：確認邏輯正確、程式碼是否容易讀懂、有沒有安全疑慮（例如 SQL injection、未授權存取）、測試是否覆蓋到重要情境。好的 code review 是一個知識傳遞的機會——reviewer 可以提醒作者更好的寫法，作者也能在回應中解釋設計決策，雙方都會成長。GitHub 上的 review 會直接標記在對應的程式碼行，讓討論有明確上下文，比在 Slack 裡講「那個 function 有問題」清楚很多。

舉個例子

你修改了使用者刪除帳號的 API，打開 PR 後請資深工程師 review。他在那行 database delete 留言「這裡沒有確認是不是本人刪自己，要加授權檢查」，你補上之後重新 push，他再次確認沒問題才 approve，PR 才得以合併。

常見誤解

- Review 只看程式碼有沒有跑起來，不檢查邊界條件、錯誤處理和安全性，結果一些顯而易見的漏洞就這樣進了 main。
- Review 時只留「LGTM（looks good to me）」或表情符號，沒有實質看過邏輯，把關的價值完全消失。
- 把所有 review 意見混為「必須改」，讓 PR 一直卡住改不完，應該區分阻擋合併的問題和只是建議的優化意見。