在快速變遷的技術浪潮中，工程師常陷入「追求最新框架」的陷阱。然而，資深 Java 顧問 Adam Bien 提出了一個反直覺的觀點：最「無聊」的標準化選擇，反而是最能對抗時間、且最適合 AI 時代的開發方式。
對於許多 Junior 工程師來說，學習框架（如 Spring）似乎是進入 Java 世界的必經之路，但 Adam Bien 建議將重心移回 Java 標準本身。
為什麼選擇「無聊」的標準？
在企業級開發中，過度依賴第三方框架會帶來巨大的維護成本。每當框架版本更新或流行趨勢改變，團隊就必須面對痛苦的遷移工作。Adam 提倡的是 Zero Dependency（零依賴）或極低依賴的開發模式，優先使用 Java 標準庫、Jakarta EE 以及 MicroProfile。
這種做法的核心邏輯在於：標準（Specification）的生命週期遠比單一框架長。如果你遵循的是工業標準而非某個特定廠商的 API，你的系統將具備極強的移植性。例如，許多二十年前基於 Java EE 標準開發的專案，在遷移到現代的 Quarkus 執行環境時，幾乎只需要進行機械式的名稱替換，而不需要重新設計邏輯。
Quarkus 如何彌補標準與雲端的差距
許多開發者認為標準 Java 啟動慢、對雲端不友善，這正是 Quarkus 解決的問題。Quarkus 在保持對 Jakarta EE 和 MicroProfile 標準相容的同時，透過編譯時優化（Build-time optimization）大幅縮短了啟動時間並降低記憶體佔用。
對於工程師而言，這意味著你既能享受標準化帶來的低維護成本，又能獲得雲端原生（Cloud Native）所需的快速反饋循環與低成本運行（例如在 Serverless 環境中，更快的啟動速度直接等於更少的帳單費用）。
BCE 模式：讓 LLM 產出高品質程式碼的秘密武器
在 AI 輔助開發的時代，提示工程（Prompt Engineering）的關鍵在於提供清晰的脈絡。Adam 重新推廣了 1990 年代的經典設計模式：BCE（Boundary-Control-Entity）。
BCE 將系統垂直切分為三個簡單的層級： Boundary（邊界）：處理外部接口，例如 REST API（使用 JAX-RS）。 Control（控制）：處理業務邏輯。 Entity（實體）：處理數據模型與持久化（使用 JPA）。
為什麼這個老舊模式在 AI 時代反而有效？ 因為 LLM（大語言模型）是在海量公開數據上訓練的，而 Java 的標準規範（Spec）是公開且極其詳盡的。當你要求 AI 依照 BCE 結構並使用標準 API（如 Jakarta EE）撰寫程式碼時，AI 產出的結果幾乎沒有幻覺（Hallucination），因為它不需要去猜測某個私有框架的特殊用法，只需遵循標準規範即可。
實務建議：從單一大型設定檔轉向專精技能集
許多團隊習慣建立一個巨大的 agent.md 或 cloud.md 來告訴 AI 所有的專案規則，但這會導致 Token 浪費且容易混淆。
更有效的做法是將規則拆分為「專精技能（Skills）」。例如，分別建立 Java CLI 技能、單元測試技能、MicroProfile 伺服器技能。當你需要開發特定功能時，僅載入對應的技能集，這能顯著提升 AI 產出程式碼的精準度，並降低推理成本。
對未來系統的看法：可觀測性與主權
在系統監控方面，Adam 推薦 OpenTelemetry，因為它同樣是標準化路徑，能讓系統在不同雲端供應商之間自由遷移。
最後，關於應用程式的主權（Sovereignty），透過減少對特定雲端服務商私有 API 的依賴，並利用 Java 25 等新版本提供的輕量化特性（如零依賴腳本），開發者可以更容易地將系統從公有雲遷回私有數據中心，確保數據與技術的掌控權。
總結給工程師的建議
不要盲目追隨框架趨勢，而要深入研究語言標準。選擇一個簡單、一致且被廣泛定義的架構（如 BCE），不僅能讓你的系統在十年後依然可維護，更能讓 AI 成為真正高效的生產力工具，而非增加技術債的來源。
來源：infoq.com (Podcast: From Java EE to Quarkus and LLMs: Adam Bien’s Playbook for Boring, Future‑Proof Systems)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。