J2EE專案10大風險
原文在 http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-ten.html
避免本文所列之10大J2EE風險，確保企業級Java專案成功
作者：Humphrey Sheil
簡體中文翻譯參考：Blueski
繁體中文整理與翻譯 : Fred Wang (http://fredwang.blogspot.com)
風險1:沒有真正理解 Java, EJB, 和J2EE
這個問題可以分解為3個部分，以便於分析：
1． 沒有真正理解Java
症狀：
A 重複開發JDK核心API中的功能或Classes
B 不懂下列中的某些項目：
- 垃圾收集器 (train, generational, incremental, synchronous, asynchronous)
- 物件在何時能被進行垃圾收集 -- dangling references
- 使用的繼承機制及其優缺點
- over-riding和over-loading方法
- 為什麼java.lang.String 提供的性能不好
- Java中的Pass-by reference語意和EJB中pass-by value語意的比較
- 使用 == 或者使用equals() 方法 for nonprimitives (非基礎型態, 基礎型態primitives有char, byte, short, int, long, float, double, boolean )
- 在不同平臺上Java threads的運行順序方式(例如是否是pre-emptive方式)
- 新線程(Green thread)和本地線程(Native thread)的比較
- Hotspot技術(以及為什麼舊的性能調整技術降低了Hotspot 的優化效果)
- JIT，以及什麼時候好的JIT變得不好
- The Collections API
- RMI
解決方案：
需要不斷加強Java方面的知識，尤其是深入瞭解Java的優勢和不足之處。Java的存在價值已經遠不止是一種語言，了解平臺(JDK及工具等)也同樣重要。嚴格地說，你應該是經過認證的Java程式師，如果不是的話，也許有時會為還有那麼多不知道的內容而感到驚訝。另外，也可以加入Java的郵件列表(Mailing List)等。從同行中學到技術，這將是你最好的資源。
備註:
如果你或者團隊中的成員不真正瞭解程式語言和平臺，怎麼還能希望企業Java應用系統能夠成功呢？能幹的Java程式師之于EJB和J2EE，就像是鴨子之于水一樣。相反的，比較弱、沒有經驗的程式師只能開發出品質低劣的J2EE應用程式。
2. 沒有真正理解EJB
症狀:
- EJB在第一次被叫用後沒有再被叫用到(尤其是stateless session bean)
- 沒有重複利用價值的EJB
- 不理解開發者要做什麼，容器(Container)提供什麼
- EJB沒有依照規範定義(fire thread, 載入了native libraries，試圖執行I/O，等等)
解決方案:
要加強關於EJB方面的知識，可以找一個周末來閱讀EJB規範 (1.1版有314頁)，然後閱讀2.0規範(524頁!)，這樣可以瞭解到1.1沒有定義而在2.0規範中補充的內容。EJB開發者從18.1及18.2章節開始閱讀是比較合適的。
備註:
不要從供應商(Vender)的角度去看EJB，要確切地知道規範所支援的標準EJB模型和基於這些模型的特殊應用之間的區別。這也有助於移轉到別的供應商平台(或版本)的時候所用。
3. 沒有真正理解J2EE
症狀:
- "Everything is an EJB"的設計方式
- 用手工交易(transaction)管理取代了容器-提供(container-provided)的機制
- 自行設計安全機制 -- J2EE平臺在企業級計算中，從表示邏輯到後臺處理，已具有最完整的整合安全架構。
解決方案:
學習J2EE的關鍵元件，並且瞭解它們的優缺點，依次用它們替代每一個服務；“知識就是力量”在這裏行之有效。
備註:
只有知識能夠彌補這些問題。好的Java開發者會成為好的EJB開發者，此後也應逐漸成為J2EE得道高手。Java和J2EE知識掌握得越多，設計和開發工作就會越出色。在設計階段一切都會有條不紊。
風險2: 過度設計(Over-engineering) (採用 EJB或者不採用EJB)
症狀:
- 過於龐大的EJB
- 開發者無法解釋EJB做什麼，以及其間的關係
- 當需要重複使用某些EJB、元件或服務時, 卻無法做到
- EJB啟動了新的交易，而該交易本該由一個已存在的EJB啟動
- 為了安全，把資料分離級別(Data isolation levels)定得太高
解決方案:
過度工程化的解決之道就是極限編程 (XP)方法：用最小的設計和程式碼來滿足需求。除非明確知道今後可能的需求，如將來的負載要求，或者系統在最高負載下的表現，否則大可不必為系統將來的情況做太多考慮或猜測。另外，J2EE平臺已經定義了可擴充性(scalibility)及容錯(failover)等特性，可以讓伺服器系統為你進行處理。
在小型系統中，只包含一個個小元件，這些元件只做一件事，且只要把這件事做好，系統穩定性就已經得到了提高，而且，系統的可維護性會變得很強，在未來要增加功能以滿足新的需求也將變得容易。
備註:
除了上面所列方案之外，可以運用設計模式(Design Pattern) -- 它們可以顯著地改進你的系統設計。EJB模型也廣泛使用了設計模式。例如，每個EJB所帶的Home 介面就是Finder和Factory模式的實例。EJB的remote介面扮演了一種實際bean實現的Proxy，並且對於提供容器的能力也是至關重要的，這些容器截取叫用信號並提供如透明（transparent）的負載平衡的服務。
另外：僅僅是為了使用EJB而使用EJB是危險的。在你的應用系統中的某一部分可能並不需要EJB，甚至你的整個應用系統都不需要。這是過度工程化所走的極端，而且我確實也目睹了一些良好的servlet和JavaBean應用被重構為EJB，而這樣做並沒有很好的技術上的理由。
風險3: 沒有將商業邏輯與前端顯示邏輯分離
症狀:
- 過於龐大、不便的JSP程式
- 在商業邏輯改變的時候必須修改JSP
- 在要求改變使用者介面顯示的時候需要修改並重新配置EJB和其他後臺元件
解決方案:
J2EE平臺使你有機會將顯示邏輯和流程控制分離，進而與商業邏輯分離。這稱為Model 2架構。
備註:
使用一致性的設計來進行用戶介面框架(UI Framework)的連接(例如可以使用taglibs)，這將幫助你避免邏輯分離的問題。不要擔心需要自己建構GUI framework, 已經有許多現成的應用可供選擇(例如Struts等, 對每一個分別進行評估，然後採用最合適的框架(framework)。
風險4: 沒有在開發環境中進行適當的配置
症狀:
- 經過多日或數周的時間才能轉到實際(Live)系統
- 上線過程仍存在大量的風險，有很多不確定性及主要的功能情境(scenario)沒有被測試到
- 實際(Live)系統中的資料和開發、測試中的資料不同
- 無法在開發者機器上進行建構 (Build)
- 應用行為在開發、測試及生產環境中各不相同
解決方案:
解決之道是忠實地複製實際(Live)環境到開發環境，讓開發環境接近於要上線的實際環境。如果未來環境是JDK 1.2.2及Solaris 7，那麼不要在JDK 1.3及Red Hat Linux上進行開發。對於所用的應用伺服器也是如此。不可預期的資料透過下面過程就不會發生：
- 資料核對(Validation)規則
- 系統行為測試
- 系統元件間的協定(特別包括：EJB-EJB間以及EJB-資料庫間)
最糟糕的是，這樣還可能發生異常、空指標，以及你從沒見過的問題。
備註:
開發人員常把安全性問題放到Test階段才開始解決。要防止這樣的陷阱產生，你也可以花費同樣多的時間在業務邏輯中改進安全性。
上線(Go live)是一個複雜的過程，其中充滿了技術性問題和非技術性問題。你可能會陷於想不到的問題中。開發及測試環境過程提供更多產生這些問題的機會，及發現這樣的問題的地方，利用它，就可以大大減少風險。
你做的專案越多，你就越能瞭解什麼是可行的，什麼是不可行的。盡量將工程問題記錄下來，以避免同樣的錯誤重複發生。
風險5: 選擇了不當的供應商
症狀:
- 開發人員要使用更多的時間來處理工具方面的問題，而不是很有成效地使用這些工具
- 為了應付已知的和未知的問題，而不得不進行大量的系統重新設計
- 在不同的工具之間很難進行整合（應用伺服器與IDE工具，IDE工具與除錯器，原始碼控制與建構(Build)工具，等等）
- 對於IDE工具和除錯器等，開發人員往往排斥它們，而推崇自己所喜歡的工具
解決方案:
為了避免風險5，你需要一個很好的供應商選擇程序，風險10的解決方案也適用於此。
要真正評估IDE工具的方法就是實際地使用它。而評估一種J2EE應用唯一的方法是建立一種概念試驗(POC)來進行證明，在試驗中要包含你的應用框架。你不會希望在花費了3個月時間進行了培訓和開發後，在使用時又發現一些bug。
假設在開發到一半的時候，突然發現你的工具集有問題，你就會發現工具的驗證比其他的事情更為重要。如果所選的應用伺服器不能充分滿足你的需要，你只好修改原先的設定。如果IDE不好，則需要設置最低限度的程式設計標準，並讓開發人員任意選擇他們認為最有效的工具。
備註:
要真正瞭解到哪一個供應商對一項特殊的任務來說最合適，其實並不是一件一次性決定的事情。你需要不斷地跟蹤與評估這個市場。例如，在過去的一年裏我用過4種不同的IDE工具，這取決於我使用了什麼樣的應用伺服器、平臺，是否使用EJB等。
風險6: 不瞭解你的供應商
症狀:
- 開發所用時間超過了最壞預測的時間1/3以上
- 供應商已經提供了某項功能，但開發者在不知道的情況下重新進行了該項功能的開發
解決方案:
為了避免這樣的風險，可以訂閱供應商的網上資源，例如郵件列表、新聞群組、版本資訊（尤其是其中的bug修復的說明等），你能從中得到無法估量的重要資訊。
一旦你已經選定了供應商，那麼立即就要投資進行培訓，並且盡可能趕在專案啟動以前完成。然後，逐漸在團隊中建立對此供應商的認識及信任。試著建立幾個EJB並部署一下，再用表示層技術 (Swing GUI, JSP等)來叫用它們。如果你既要建立開發環境，又要同時在實現專案目標，就會產生一些不必要的衝突。實際上，我也見到過一直沒有進行建構過程的情況：“我們沒有時間。”因此，這些工作必須提早進行。有些人會說：“我們的計劃中沒有為我們提供這些時間。”我的回答是：“你的計劃中並沒有不給你時間使你不這麼做啊。”
備註:
在J2EE世界裏，各供應商產品的技術相容性究竟如何？讓我們看一下IBM和BEA的具體分析吧。兩者都分別在各自的應用伺服器中支援EJB 1.1。那麼，實際上BEA WebLogic 5.1和IBM WebSphere 3.5究竟有多少相似之處呢?
1. BEA WebLogic和IBM WebSphere的系統配置和管理方式幾乎完全不同。
2. IBM在WebSphere中採用了全面的GUI環境，而與之相對的是，BEA 在WebLogic中提供一整套命令行。
3. IBM WebSphere使用IIOP來和CORBA異常進行通訊，這些異常對程式師來說是可見的；WebLogic根本沒有CORBA構造，而預設使用t3協定。
4. WebSphere和Visual Age銜接緊密，而WebLogic是IDE無關的，實際上，你幾乎可以使用任何的開發工具。
由此可見，差異還是相當多。如果你是一種應用伺服器的專家，並不意味著你就是所有應用伺服器的專家。這種差異主要在IDE，debugger，build工具，配置管理等等方面。具備某供應商的某項特殊工具的使用經驗，可以在評估該供應商的競爭對手產品時具有一些便利。但是，不要奢望在不同產品之間進行無縫(seamlessly)的轉移。因此，你不得不花費更多的時間在熟練掌握這些工具。
風險7: 設計中沒有充分考慮到可擴充性和產品性能
症狀:
- 無法忍受的緩慢速度
- 系統給伺服器端增加的沈重負擔，而無法利用到一些聚簇(Clustering)技術。
解決方案:
把精力集中於性能和可擴充性(Scability)方面的需求，明確開發要達到的性能指標。如果你需要每秒50個交易，而你的EJB設計只能提供40個，那你就需要考慮替代方案，諸如儲存過程，批次處理，或者重新考慮OLTP的設計。
盡可能讓你的供應商加入，他們應該非常清楚其產品的強項和弱處在哪裡，然後給你提供最直接的幫助。
備註:
本風險與風險2 (over-engineering)似乎有些衝突。實際上，兩者相互影響。 我對風險2給出的解決方案是，只在絕對必要的情況下才進行構建。而對與性能和可擴充性，你要預先劃分好什麼是必須要做的。
如果你認為強大的可擴充性是關鍵的需求，那首先需要選擇一個有很強的Cluster支援及Transactional Cache的應用伺服器。另外，應把業務物件(Business Object)設計為EJB，以充分利用伺服器架構的優勢。
風險8: 過時的開發過程
症狀:
- 專案計劃看上去類似瀑布模型: “首先進行系統設計，然後在一個很長的周期裏進行開發。”
- 由於沒有構建（build）程序，因此每次構建都像是噩夢
- 構建的日期等於損失開發的日期，因為什麼也沒有做成
- 在整合以前元件沒有分別被充分地測試過，而整合測試意味著將2個不穩定的元件放在一起，然後查看堆疊裏的追蹤(Trace)結果。
解決方案:
好的軟體方法學將提高你的軟體生命期。此前我已經提到XP方法，你可以在網上找到很多這方面的資料。
備註:
JUnit可以用來進行單元測試，Ant工具可以進行編譯與構建，這2種工具都對XP方法有很好的支援。
風險9: 沒有好的架構(Framework)
症狀:
- 核心庫中有Bug的部分在程式碼中使用了很多次。
- 沒有建立日誌(Logging)標準 -- 因此系統的輸出很難讀取或者解析。
- 不良且不一致的異常處理。在有些網站中甚至可以看到，低階的系統錯誤訊息直接顯示使用者，例如在使用者在他的購物車核帳時發送一條SQLException Stack Trace資訊，用戶接著會怎麼做？打電話給資料庫管理員要求修正primary key限制嗎？
以下工作已經以各種方式處理過，這些應該列為架構設計的首要目標。
- 日誌(Logging)
- 異常處理 (Exception handling)
- 與資源的連接(資料庫，Naming service等)
- 建立JSP頁
- 資料正確性檢查(Data Validation)
解決方案:
我是一個輕架構(Lightweight Framework)的信徒和實踐者。我在JavaWorld 上的第一篇文章 -- "Frameworks Save the Day" -- 就是研討在企業Java環境中的架構。即使你已經開始開發，此時考慮一下架構仍然是值得的。可能你不得不忍受一下重構帶來的異常處理和日誌處理，但從長遠來看還是值得的，這樣既省時間又省錢。
備註:
思考一下架構及元件開發的可重用性區分不同等級。第一級別是plumbing，具有0.9以上的可重用比例，也就是說，有90%的專案可以對它重複利用。 服務越特殊，重用比例就越低。換句話說，我需要建立一個會計服務，以提供資源的使用及管理，並便於其他50%專案中可以對它們進行重複利用。對那些需要這些資源的專案開發者來說，能得到這些資源，那真是太棒了！
風險10: 根據市場宣傳決定專案計劃和設計，而非實際技術需求
症狀:
- 輕率地進行技術決策，認為EJB只是為了可移植性(portable)的目的
- 選擇供應商的時候沒有隨即進行產品的試用
- 在專案的生命周期內還需要更換工具
解決方案:
不要輕易相信專案外部的任何人的看法，這些人可能已經有一些既得利益，不要相信供應商的說法（除非你早已經瞭解），也不要相信白皮書。如果要取得關於應用伺服器的建議，可以在網上取得。還可以下載這些工具進行評估，用它們做一些原型(prototype)，並執行一下其中的案例。(好的供應商都有這樣的案例)。
總而言之，你的專案選擇最好的供應商及工具需要時間，而你可能沒有太多的時間。你可以把選擇範圍限制在3-4個種，然後用一周時間進行比較和檢驗。最後從中選出比較滿意的工具和產品。
備註:
如果你缺少J2EE經驗，則可能會在專案前期就產生問題。在前期所確定的決策會影響整個過程，並進而影響專案的成功。好的J2EE諮詢專家將能夠幫助你選擇好的供應商，並為設計和開發刻劃出一個好的架構。
結論
總而言之，以上10大風險是企業級Java專案開發過程中將面對的主要困難。相信在你的旅程中一定還有更多的陷阱，相信上面所提到的風險已經涵蓋了主要的問題。最後按照優先順序重新列舉一下10大風險：
- 沒有真正理解Java, 沒有真正理解EJB, 沒有真正理解J2EE
- 過度設計(Over-engineering)
- 沒有將業務邏輯和顯示邏輯相分離
- 沒有在開發環境中進行適當的配置
- 選擇了不當的供應商
- 不瞭解你的供應商
- 設計中沒有充分考慮到可擴充性和產品性能
- 過時的開發過程
- 沒有好的架構(Framework)
- 根據市場宣傳決定專案計劃和設計，而非實際技術需求