診斷 Java 代碼：走鋼索般的規範平衡術——精確度、成本與可執行文檔的抉擇

構建可靠軟體，程式規範至關重要。沒有良好定義的規範，難以診斷系統異常行為；然而許多系統規範定義糟糕，甚至完全缺失。規範本質是對程式行為的描述，形式可正式化也可鬆散，取決於系統穩定性需求、危險程度及部署後修改難易度。

精確度的成本與收益平衡

微處理器設計領域，部署後修改成本極高，因此規範正式化程度極高，甚至可自動驗證設計正確性。軟體界最類似的是程式語言：廣泛使用、危險等級不一、修改成本高昂，故語言規範通常較正式（特別是語法，現代語言皆有正式文法，解析器多由生成器自動產生）。但語義規範常以敘述性文字為主，原因在於：證明語言特性比硬體更難、非正式規範給編譯器作者優化空間、程式設計師偏好易讀規範、許多語言由非專業愛好者開發。

模糊規範的代價

• C++：規範模糊甚至語法層面曖昧，大量實現相關細節，導致跨平台行為難預期。
• Python：大量實現相關/未定義細節，Jython 與 CPython 行為一致性極難保證。
• Java：雖無 ML 式正式規範，但投入大量精力打造精確非正式規範；JVM 規範良好（經正式分析發現模糊處），API 納入 JVM 規範，實現空前可移植性。

結論：盡可能精確的規範極有用，但預先定義成本高，許多公司選擇先交付產品再補充細節（或永不）。對於生命週期短、部署窄的應用，預先精確規確實過於昂貴。

為何「實現即規範」是最糟糕的做法

許多專案無規範直接實現，完工後以實現作為規範。缺點顯而易見：

1. 實現包含任意選擇，未來移植需從海量細節中推導必要行為。
2. 本質上將所有行為視為有意，無法判定錯誤（廠商常將有害行為標為「正常」）。
3. 初始開發者需依賴心智模型，實現尚不存在時無從參考。

劃算的規範：極限編程（XP）的用戶故事

規範可分段開發，降低複雜度，適應需求變更。XP 中以用戶故事漸進確定系統功能，每個故事簡述行為一面，如：

「當用戶在編輯器輸入文字時，Java 關鍵字自動顯示為藍色，字串與字元字面值為綠色，註解為紅色。」

故事細小、語言清晰、易拆分、防止耦合、易更新。這正是工業界頻繁變更需求時的理想規範形式。

單元測試不是完整規範

單元測試是 XP 核心，編寫於實現之前，覆蓋所有功能面。優勢在於：

• 可執行文檔：新成員閱讀測試即理解組件用途。
• 加速重構：隨時運行測試檢測回歸錯誤。

但單元測試不能替代完整規範：

1. 測試集必然不完整，無法覆蓋所有輸入/狀態，「最合理範圍」模糊不清。
2. 測試強制特定實現細節，同樣存在「實現即規範」的缺點。

最佳定位：單元測試是規範的補充，而非替代品。

結語

設計軟體系統需擁有盡可能精確的規範，XP 模組化故事結構能平衡成本與收益。切勿將實現誤作規範，也勿過度依賴單元測試企圖涵蓋所有規範定義。下一期將探討 Java 泛型的更多細節。