在各種各樣的風險中，有些風險只是延緩了專案的進度，有些帶來了一些不必要的工作，而另一些則會把成功的可能性徹底地消除。下面小編總結了J2EE專案開發的風險，提供給大家參考!
風險1:沒有真正理解 Java, EJB, 和J2EE
這個問題可以分解為3個部分，以便於分析。
描述: 沒有真正理解Java
專案階段:開發
影響階段：設計、穩定性測試、成熟期
對系統性能的影響：可維護性、可擴充套件性、效能
症狀：
重複開發了JDK核心API中的功能或類
不懂得以下列表中的某些項(這只是一些主題或者實際例子而已)：
垃圾收集器 (train, generational, incremental, synchronous, asynchronous)
物件在何時能被進行垃圾收集 dangling references
使用的繼承機制及其權衡
overriding和overloading方法
為什麼ng (在這裡用你所中意的類代替) 提供的效能不好
Java中的passby參考語義和EJB中passby值的語義的比較
使用 == 或者使用equals() 方法 for nonprimitives
在不同平臺上Java執行緒的執行順序方式(例如是否是搶先方式的)
新執行緒和本地執行緒的比較
Hotspot技術(以及為什麼舊的效能調整技術降低了Hotspot 的優化效果)
JIT，以及什麼時候好的JIT變得不好(未安裝的JAVA編譯器，以及你的程式碼執行得剛夠良好)
API蒐集
RMI
規避方案：
你需要不斷改進Java方面的知識，尤其是深入瞭解Java的優勢和不足之處。Java的存在價值已經遠不止是一種語言，理解平臺(JDK及工具等)也是同樣重要的。具體地說，你應該是經過認證的Java程式設計師，如果你不是的話，也許你有時會為還有那麼多不知道的內容而感到驚訝。另外，你可以加入Java的郵件列表。以前我曾加盟過的每一個公司都加入了這樣的郵件列表，從同行中學到技術，這將是你最好的資源。
備註:
如果你或者你的團隊中的成員不真正瞭解程式語言和平臺，怎麼還能保持成功的希望呢?強幹的Java程式設計師之於EJB和J2EE，就象是鴨子之於水一樣。與此相反，比較弱的、沒有經驗的程式設計師只能開發出質量低劣的J2EE應用程式。
描述: 沒有真正理解EJB
專案階段:
設計
影響階段:
開發、穩定化
對系統的影響:
維護
症狀:
EJB在第一次被呼叫後沒有再被使用到(尤其是stateless session bean)
沒有重複利用價值的EJB
不理解開發者要做什麼，容器提供什麼
EJB沒有依照規範定義(fire執行緒, 載入了本地庫，試圖執行I/O，等等)
解決方案:
要改進關於EJB方面的知識，可以找一個週末來閱讀EJB規範 (1.1版有314頁)，然後閱讀2.0規範(524頁!)，這樣可以瞭解到1.1沒有定義到的而在2.0規範中補充的內容。EJB開發者從18.1及18.2章節開始閱讀是比較合適的。
備註:
不要從提供商的角度去看EJB，要確切地知道規範所支援的標準EJB模型和基於這些模型的特殊應用之間的區別。這也會有助於你遷移到別的提供商的時候所用。
描述: 沒有真正理解J2EE
專案階段:
設計
影響階段:
開發
對系統的影響:
維護、擴充套件性、效能
症狀:
"Everything is an EJB"的設計方式
用手工事務管理取代了容器提供的機制
自定義方式的安全處理 J2EE平臺在企業級計算中，從表示邏輯到後臺處理，已具有最完整的整合安全架構;但很少用到其全部功能。
解決方案:
學習J2EE的關鍵元件，並且瞭解它們的優缺點，依次用它們替代每一個服務;“知識就是力量”在這裡是行之有效的。
備註:
只有知識能夠彌補這些問題。好的Java開發者會成為好的EJB開發者，此後也應逐漸成為J2EE得道高手。Java和J2EE知識掌握得越多，設計和開發工作就會越出色。在設計階段一切都會有條不紊。
風險2: 過度設計(Overengineering) (採用 EJB或者不採用EJB)
專案階段：
設計
影響的專案階段:
開發
對系統的影響:
維護、擴充套件性、效能
症狀:
過於龐大的EJB
開發者無法解釋EJB做什麼，以及其間的聯絡
無法重複使用的EJB、元件或者服務
EJB啟動了新的事務，而該事務本該由一個已存在的EJB啟動
為了安全，把資料分離級別定得太高
解決方案:
過度工程化的解決之道直接來自於極限程式設計 (XP)方法：用最小的設計和程式設計來滿足需求，除此之外別無它幹。除非你需要明確知道今後可能的需求，如將來的負載要求，或者系統在最高負載下的表現，否則大可不必為系統將來的情況做太多考慮或猜測。另外，J2EE平臺已經定義了可伸縮性及出錯恢復等特性，可以讓伺服器系統為你進行處理。
在最小的系統中，只包含一個個小元件，這些元件只做一件事，只要把這些要求做到的進行實現，系統穩定性就已經得到了提高，而且，你的系統的可維護性會變得很強，在未來要增加功能以滿足新的需求也將變得容易。
備註:
除了上面所列方案之外，可以推行設計模式 它們可以顯著地改進你的系統設計。EJB模型本身也廣泛使用了設計模式。例如，每個EJB所帶的Home 介面就是Finder和Factory模式的例項。EJB的remote介面扮演了一種實際bean實現的代理，並且對於提供容器的能力也是至關重要的，這些容器擷取呼叫訊號並提供諸如透明(transparent)負載均衡的服務。忽視設計模式也是危險的一部分。
我常提到要反對的另外一種危險是：僅僅是為了使用EJB而使用EJB。在你的應用中的某一部分可能並不需要EJB，甚至你的整個應用都不需要。這是過度工程化所走的極端，而且我確實也目睹了一些良好的servlet和JavaBean應用被重構為EJB，而這樣做並沒有很好的技術上的理由。
風險3: 沒有將業務規則和邏輯表現形式相分離
專案階段：
設計
影響的專案階段：
開發
對系統的影響:
維護、擴充套件性、效能
症狀:
過於龐大、沒有邊際的JSP程式
在業務邏輯改變的時候必須修改JSP
在要求改變介面顯示的時候需要修改並重新配置EJB和其它後臺元件
規避方案:
J2EE平臺使你有機會將表示邏輯和導航控制相分離，進而與業務規則相分離。這被稱為模式2結構。
備註:
可以使用具有一致性的設計來進行使用者介面框架的連線。(例如可以使用taglib)，這將幫助你避免邏輯分離的問題。有許多現成的好的方法可供選擇。對每一個分別進行評估，然後採用最合適的框架。
風險4: 沒有在開發環境中進行適當的配置
專案階段：
開發
影響的專案階段:
穩定化、併發、成熟期
對系統的影響:
你的權衡
症狀:
經過多日或數週的時間才能過渡到成熟系統
風險存在與過渡期，帶有很多不確定性，有些主要的功能場景沒有被測試到
實際系統中的資料和開發、測試中的資料不同
無法在開發者機器上進行組建
應用行為在開發、穩定化及產品環境中各不相同
規避方案:
解決之道是忠實地在開發環境中配置實際的環境，讓開發所用環境接近於要實施產品的環境。如果未來環境是JDK 1.2.2及Solaris 7，那麼不要在JDK 1.3及Red Hat Linux上進行開發。對於所用的應用伺服器也是如此。同樣，要快速地看一下產品資料庫中的資料，並將這樣的資料用於測試。不要依賴於人工建立的資料。如果產品資料很敏感，則要使之變得不敏感，然後把它配置起來。開發中未能預期到的產品資料將對以下過程產生破壞：
資料檢驗規則
系統測試行為
系統元件構建(特別地包括：EJBEJB以及EJB資料庫)
最為糟糕的是，這樣還可能產生異常、空指標，以及你從沒見過的問題。
備註:
開發人員常把安全性問題放到穩定化階段才開始解決。要防止這樣的陷阱產生，你也可以花費同樣多的時間在業務邏輯中改進安全性。
成熟期是一個複雜的過程，其中充滿了技術性問題和非技術性問題。你可能會陷於想不到的一大堆問題中，這就是成熟化所意味的一切。開發及穩定化環境過程為你提供了製造更多這樣的問題，以及發現這樣的問題的地方，不斷去做，就可以大大減少風險。
你做的工程越多，你就越能瞭解什麼是可行的，什麼是不可行的。你可以對工程問題進行記錄，以避免同樣的錯誤重複發生。
風險5: 選擇了錯誤的提供商
專案階段：
提供商選擇
影響階段：
設計、開發、穩定化/負載測試，成熟化
對系統的影響:
可伸縮性、效能、可維護性及穩定性
症狀:
開發人員要使用更多的時間來處理工具方面的問題，而不是很有成效地使用這些工具
為了應付已知的和未知的問題，而不得不進行顯著的系統重新設計
在不同的工具之間很難進行整合(應用伺服器與IDE工具，IDE工具與偵錯程式，原始碼控制與合成工具，等等)
對於IDE工具和偵錯程式等，開發人員往往排斥它們，而推崇自己所喜歡的工具
規避方案:
為了避免風險5，你需要一個很好的提供商選擇過程，風險10的規避也適用於此。
要真正衡量一種IDE工具是否最合適的方法是真正地進行使用。而唯一來評估一種J2EE應用的方法是建立一種概念試驗來進行證明，在試驗中要包含你的應用框架。事實上，你也不希望在花費了3個月時間進行了培訓和開發後，在使用時又發現一些bug。
假設在開發到一半的時候，突然發現你的工具集有問題，那麼你早應該知道，有些工具確實比另一些更重要。如果你所選的應用伺服器不能充分滿足你的需要，你只好修改原先的設定。如果IDE不好，則需要設定最低限度的程式碼標準，並讓開發人員任意選擇他們認為最為有效的工具。
備註:
要真正瞭解到哪一個供應商對一項特殊的任務來說最合適，其實並不是一件一次性決定的事情。你需要不斷地跟蹤與評估這個市場。例如，在過去的一年裡我用過4種不同的IDE工具，這取決於我使用了什麼樣的應用伺服器、平臺，是否使用EJB等。
