Code Review 是前端面試中很能看出資深度的題目。
它不是在問你會不會挑錯，而是在看你是否能從功能、維護性、風險、測試和團隊協作的角度看程式碼。
怎麼描述一次 Code Review 經驗？
不要只說：
我會看命名、排版、邏輯。
這樣太抽象。
比較好的回答是講一個具體情境：
我曾經 review 一個商品列表篩選功能。那個 PR 同時改了 UI、API query、URL state 和列表快取。我主要看三件事：需求是否符合驗收條件、filter 狀態是否能和 query string 同步、以及列表是否有不必要 re-render。最後我建議補 empty state、把 filter 狀態同步到 URL，並把 API 錯誤處理抽成共用 helper，避免其他列表頁重複實作。
這樣會讓面試官感覺你真的做過 review，而不是背清單。
Code Review 通常看哪些東西？
1. 功能正確性
- 是否符合需求與 acceptance criteria
- edge case 是否處理
- loading / empty / error state 是否完整
- 權限與登入狀態是否正確
2. 可維護性
- 命名是否表達意圖
- component 是否過大
- 重複邏輯是否可以抽出
- abstraction 是否過早或過度
- 檔案位置是否符合專案慣例
3. React 品質
- state 放的位置是否合理
- effect dependency 是否正確
- key 是否穩定
- 是否有不必要的 re-render
- 表單、modal、route 狀態是否同步正確
4. 安全與資料處理
- token 或 secret 是否暴露到前端
- API error 是否洩漏敏感訊息
- 使用者輸入是否有處理
- 權限檢查是否只依賴前端
5. 測試與可觀測性
- 重要流程是否有測試
- 是否有容易壞的條件沒覆蓋
- 錯誤是否有 log 或監控事件
- 是否容易在 staging 驗證
好的 review comment 長什麼樣？
不太好的 comment：
這樣寫不好。比較好的 comment：
這裡的 filter state 只存在 component 裡，重新整理後會遺失。
因為這個頁面需要支援分享篩選結果，建議同步到 query string。好的 comment 通常包含：
- 問題在哪裡
- 為什麼是問題
- 建議怎麼改
- 如果只是偏好，要標註 nit
Code Review 不是證明自己比較厲害，而是降低未來維護成本。
常見追問
如果你不同意對方寫法怎麼辦？
先分清楚是 bug、風險，還是個人偏好。
如果是偏好，可以用 question 或 suggestion 的方式：
這裡有沒有考慮沿用現有的 usePagination hook？這樣其他列表頁的行為會比較一致。時間很趕還要 review 嗎？
要，但可以聚焦高風險項目：功能正確性、資料安全、錯誤處理、主要流程測試。樣式偏好或小重構可以留到後續。
大 PR 怎麼 review？
我會先看 PR description、需求範圍和主要檔案，再分層看資料流、UI、測試。如果 PR 太大，也會建議之後拆成較小 PR。
面試回答模板
我做 Code Review 會先看功能是否符合需求，再看 edge case、狀態管理、錯誤處理、效能、安全和測試。我會盡量讓 review comment 有脈絡，說明為什麼這是問題，以及建議怎麼調整。如果只是個人偏好，我會標成 nit，不會把偏好包裝成必改。對我來說 Code Review 的重點是降低風險和提升可維護性，而不是單純挑錯。