危機一：不懂 Java / EJB / J2EE 基礎
- 現象：重造 JDK API、不懂 GC/線程模型、濫用繼承、用
== 比較對象、忽略 Collections/RMI。
- 對策：考取 Java 認證、建立技術郵件列表、向同儕學習、深讀規格書。
危機二：過度設計
- 現象：巨型 EJB、無法解釋職責、不可復用、事務濫用、隔離級別過高。
- 對策：遵循 XP「最小可行設計」、善用設計模式（工廠、代理、DAO）、拒絕「為用 EJB 而用 EJB」。
危機三：表現邏輯與業務邏輯未分離
- 現象：巨型 JSP、Scriptlet 混雜 SQL/業務規則。
- 對策：採用 MVC、Business Delegate、DAO 模式，JSP 僅負責渲染。
危機四：忽略非功能性需求
- 性能、擴展性、安全性、可維護性需在設計階段納入架構考量，而非事後補救。
危機五：供應商鎖定
- 避免依賴特定應用服務器專有 API，堅持標準 J2EE 規範，保持遷移彈性。
危機六：缺乏自動化建構與測試
- 引入 Ant/Maven、JUnit、持續集成，確保每次提交可構建、可測試。
危機七：配置管理混亂
- 環境差異導致部署失敗，採用外部化配置（JNDI、屬性文件）、版本控制所有配置。
危機八：數據庫設計缺陷
- 無索引、過度正規化/反正規化、缺乏分頁查詢優化，需 DBA 介入審查。
危機九：忽略生產環境監控
- 上線無日誌聚合、無告警、無追蹤，導致故障排查困難。引入 APM、集中式日誌。
危機十：團隊溝通與知識傳承斷層
- 文檔缺失、代碼評審流於形式、核心成員離職項目癱瘓。建立 Wiki、結對編程、輪崗機制。
總結
成功的 J2EE 專案建立在扎實的技術基礎、克制的設計、自動化工程實踐與良好的團隊文化之上。架構師需在設計與性能、標準與具體實現間取得平衡。
