命名規範
- 駝峰命名：類名首字母大寫，方法/字段/變量小寫開頭，單詞界限大寫。常量全大寫下劃線分隔。包名全小寫。
類設計原則
- 經典類模板：通用類實現
equals()、hashCode()、toString()、clone()（實現 Cloneable）、Serializable
- 內置測試入口：每個類提供
main() 單元測試代碼，無需刪除，便於回歸驗證與示例演示
- 單一職責：方法短小精悍，僅完成一件事；過長方法拆分。類解決單一問題，避免「上帝類」
- 面向使用者與維護者：API 設計清晰易用，預留擴展點，降低修改成本
- 拆分信號：複雜 switch → 多態；大量類型判斷方法 → 拆分類；成員差異大 → 拆分類
封裝與訪問控制
- 最小暴露原則：默認
private，僅公開必需 API。多線程下 private 字段天然線程安全
- 拒絕巨型對象：對象表達領域概念，非流程腳本容器
- 醜陋代碼隔離：不得已的 hack 封裝在類內部，不外洩
- 內部類善用：緊耦合類考慮內部類改善封裝
代碼質量習慣
- Javadoc 文檔化：細緻註釋，生成專業 API 文檔
- 消除魔術數字：語義化常量替代硬編碼數值，提升可讀性與可維護性
- 構造器異常處理：構造失敗時重新拋出異常，避免調用者持有半初始化對象
- 顯式清理協議：提供
cleanup() 方法 + boolean disposed 標記，finalize() 兜底檢查並拋出 RuntimeException 揭露泄漏
- try-finally 確保釋放：非 GC 管理資源（流、連接、鎖）必須在
finally 中釋放
總結
這 15 條建議貫穿命名、設計、封裝、異常、資源管理全生命週期，堅持執行能顯著提升代碼的可讀性、健壯性與可維護性。建議打印張貼工位，Code Review 時對照檢查。
