Java 開發者必守的 10 條鐵律：從註解到品質文化

前言

程式碼是給人看的，順便給機器執行。這 10 條守則源自實戰慘痛教訓，違者必有災難。

鐵律 1：寫註解，寫給六個月後的自己

未註解代碼 = 技術債務。Javadoc 規範：類別、公用方法、複雜演算法必註。註解要解釋「為什麼」，而非「做什麼」（程式碼已說明做什麼）。

鐵律 2：別把簡單問題複雜化

• 5 使用者的系統別引入 EJB/分散式架構。
• 不需要框架時別硬套框架。
• KISS 原則：Keep It Simple, Stupid。

鐵律 3：「少即是多」不適用於可讀性

單行三元運算子、巢狀邏輯壓成一行 → 除錯地獄。拆分成多個 if、引入說明性變數、犧牲幾行代碼換取清晰度。

// 坏：單行難讀
if (a.equals("SD") && (sellOff==null || today.before(sellOff) || (lastUsed!=null && today.after(lastUsed))) || ...) { ... }

// 好：拆分、命名
boolean isSdValid = a.equals("SD") && (sellOff==null || today.before(sellOff) || (lastUsed!=null && today.after(lastUsed)));
boolean isObsValid = a.equals("OBS") && (obsDate==null || today.before(obsDate));
if (isSdValid || isObsValid) { ... }

鐵律 4：杜絕硬編碼

魔術數字、字串散落各處 → 維護噩夢。定義 static final 常數，集中管理。

public static final String STATUS_ACTIVE = "ACTIVE";
if (STATUS_ACTIVE.equals(status)) { ... }

鐵律 5：別造輪子，除非你在造車

成熟框架經過百萬行生產驗證。Struts/Spring/Hibernate 解決通用問題，業務邏輯才是你的價值。簡單系統（3 頁面）不需要 Struts。

鐵律 6：拒絕 System.out.println 與字串連接洩漏效能

• System.out.println 同步鎖 + I/O，迴圈中會拖垮效能（實測 10,000 次：無輸出 0.001s vs 有輸出 10.5s）。
• 字串 + 產生大量中間物件，改用 StringBuilder/StringBuffer（實測 20 次：String 0.08s vs StringBuffer 0.01s）。
• 導入日誌框架，log.debug() 可由等級控制輸出。

鐵律 7：重視 GUI，它是產品的臉面

• 別讓開發者充當設計師，除非你雙棲。
• 先做原型，早獲用戶回饋。
• 戴上用戶帽子：分頁、搜尋、錯誤提示友善度。

鐵律 8：需求文檔先行（敏捷不等於無文檔）

哪怕一頁紙、一張白板照，也要留下痕跡。口頭需求 = 不存在的需求。

鐵律 9：單元測試，單元測試，單元測試

• TDD：先寫測試再寫代碼。
• 測試所有「有趣」的 public 方法（Getter/Setter 除外，除非含邏輯）。
• 保留測試註解，它是活文檔。

鐵律 10：品質 > 數量，準時下班是專業表現

長工時 ≠ 高產出。健壯、少 Bug、可維護的代碼才是核心資產。經理買單的是品質，而非加班時數。

結語

知易行難。將這 10 條內化為肌肉記憶，你會從「寫代碼的人」進化為「工程師」。