聊聊 Code Review
Code Review 是開發過程很重要的一環，要怎麼 review
目的
- 團隊知識流動
- 資深帶資遣學習
分成等級
- Merge Blocker
- Suggestion / Nice to have
- Minor
Code Review 常見的問題
- 一次 MR/PR 太大包：
結構 / 架構
Configuration: 內部介面 (Application Internal Interface)
RESTful API 介面 公開介面 (Public Interface)
程式介面 (Code Level Interface)
Code Quality
如何確保單一職責？
單一職責 (Single Responsiblity) 是很重要的概念，但往往
- Package 的依賴性
- Libraries 依賴性
Readable 可讀性
最常見的命名
1 |
Code Convention / Standard
- 框架已經有命名原則
- 名稱的範圍
- 用主流的標準
這篇文字內容很實用，適合整理成一篇具有個人風格、清晰脈絡又適合部落格發表的文章。我幫你重新撰寫成以下格式，保留原始語氣的親切感，同時增添結構與條列，讓讀者更容易吸收：
我怎麼做 Code Review：一個 Java 開發 Lead 的觀點
最近開始比較有系統地進行 Code Review，也順手把一些原則與流程整理下來。這篇不是照本宣科的 code review 指南，而是我自己實際帶人 review、反覆口述過後，內化出來的思路與節奏。
目的也很單純：讓 Code Review 不只是一個人能做的事，而是能傳承下去的文化與流程。
🔍 Review 的流程與重點
1. 設定與 Config 改動
- 新增哪些設定？預設值是什麼？怎麼被使用？
- README.md 有沒有更新？
- 有沒有支援 debug mode 或 CLI 模式？
2. 第三方依賴（Dependency）
- 新增/刪除了哪些 library？有必要嗎？
- 是否涉及安全性修補？有沒有更適合的替代品？
- 是否重複引入相似功能（例如多個 JSON lib）？
3. 主要業務邏輯
- 根據 commit 的對應任務，確認主邏輯與需求/Spec 是否一致。
4. Code 範圍掃描（局部檢查）
- 每個 class 的 import 是否合理？
- 有沒有出現「低層依賴高層」的反常依賴？（例如 5F 依賴 1F）
- 顆粒度是否過大，導致過度耦合？
5. 結構合理性（Structure）
結構應該是樹狀，而非網狀。
- 可以依賴底層，不應反向依賴上層。
- 同層可以相依。
同一個業務 domain 的 code 應該放在一起，而不是依 class type（例如 controller 全部集中）。
避免不必要的抽象與複雜，才能提高可維護性。
6. 命名風格（Naming）
- Local variable 不需過長，重點是清楚。
- Class 與 package 的命名需一致、有意義。
7. Constants 的使用
- 檢查常數定義的正確性與作用範圍，是否濫用或重複。
8. 重構指標
- 確認是否有可重構區塊，例如重複邏輯、過長 method、神物件等。
🤝 Review 的價值，不只在 code 本身
其實我認為 code review 最有趣的，不只是抓 bug 或教學，而是文化建構的過程：
- 有理的優先，不是靠年資或頭銜：review 重點是論點與邏輯，而不是誰寫的。
- 新技術/語法需要共識：例如 Java 的 record class，要引入之前，最好團隊先達成用法共識。
- 透過 review，更了解團隊成員的實作習慣與盲點。
- 對話過程中，常常可以激出更好的解法：甚至會讓 code 變得「有趣」。
✍️ 小結：從個人到團隊的傳承
這份筆記原本只是我在帶同仁做 code review 時的口述節奏，後來覺得不該只鎖在腦袋裡，就把它寫進內部 wiki。這篇是再整理、轉成 blog 版本，也希望對其他團隊有所幫助。
雖然市面上像 Google、Microsoft 都有完整的 code review guide，但我老實說沒特別去讀，這些原則完全是來自實務經驗。也許不夠全面，但更貼近我們平常寫 Java、跑 Spring Boot、帶專案的日常。
如果你也是技術 Lead，或是想建立團隊內的 code review 流程，不妨從這幾點開始思考與實踐。
需要我幫你畫一張結構流程圖來補這篇文章，也可以說一聲。
延伸閱讀
Comments
About
著作
演講
AWS Certifications
