J2EE項目危機【翻譯】
避免這10項J2EE危機來確保你的企業JAVA項目成功
By Humphrey Sheil摘要
在你着手企業級JAVA 項目開發時，你需要像耍雜技掌控手中的球一樣來處理一些問題：與工具商之間的關係，漫長的工程——不論是設計還是開發，還是保持健壯性。每一項都會帶來固有的危險，一些是明顯的，然而另外一些卻不是。但所有這些危機均可避免。本文作者分析了10項危機企業級JAVA項目的最大的危險，並大致指出了避免它們的辦法。（4，500字——此處是指英文字數）
作者：Humphrey Sheil
原文出處：http://java.sun.com/developer/technicalArticles/J2EE/projectdangers/
翻譯：gooing 2005-01-18
http://blog.csdn.net/gooing/
感謝金山詞霸和薛叉叉，請指正!
在我作爲開發者、高級開發者、架構師的經歷中，我遇到過好的、差的甚至是醜陋的企業級JAVA項目。當我問自己，是什麼使一個項目成功而使另外的失敗，我發現很難得到一個完美的答案，就好像很難用成功來定義所有的軟件項目。J2EE項目也不例外。因此，項目被分爲不同級別的成功或失敗。在這篇文章裏，我主要想爲您——讀者朋友——揭示影響企業級JAVA項目的最大的10項危險。
一些危險只是簡單的延遲項目進度，一些卻是錯誤的徵兆，而還有一些使項目徹底沒有成功的希望。儘管如此，如果具有良好的準備，征程開始前相關的知識和熟悉地形的嚮導，所有的都可避免。
這篇文章結構簡單，我會按以下方式來揭示各種危機：
- 危機的名稱
- 項目階段（Project phase）：危機所出現的項目階段
- 所牽連的項目階段（Project phase(s) affected）：大多情況下，這些危機對隨後的“項目階段”有一種順帶（knock-on）的影響
- 解決：避免危機的方式以及如何最小化它們的影響
- 註釋：有關該危機我想透露的觀點，但不適合以前的分類
如上所注，我們將在企業級JAVA項目背景和它的各個重要階段中檢查每一項危險。這些項目階段包括：
- 供應商選擇：在你啓動J2EE工程之前，挑選你的最佳工具組合的過程——不論是應用服務器還是咖啡品牌
- 設計：不論是嚴格的瀑布模型還是"code it and see"（試翻譯爲：編碼和運行查看）方式，我對設計都有這樣一個觀點：我做了充分的設計，因此我可以輕鬆的進入開發階段。當我確切知道我在建造什麼和如何建造時，我認爲我的設計階段完成。另外，在進入開發階段之前，我使用設計模板來保證我對我自己問了所有正確的問題並且有了建議的解決方法。然而，我在該階段同樣也不害怕寫代碼；有時，這是回答問題的唯一方式，執行和模塊化（ performance or modularity）。
- 開發：這個階段早期有大量工作要做。選擇好的工具加上一個良好的設計並不總是意味着開發階段會非常順利，但的確會很有用。
- 穩定性/負荷測試：在這個階段，系統架構師和項目管理員將關注系統健壯性和構建質量，如確保系統的關鍵統計——併發用戶數，失敗的情境等。然而，直到這一階段，代碼質量和運行亦不應被忽略。事實上，你不能留一些差的或慢的代碼到健壯性階段來改。
- 存在階段[live]：這並不是真正的項目階段，it's a date set in stone（想了半天也不知道怎麼翻譯:-{）這是關於準備的階段，也是以前的錯誤的鬼怪出沒的地方，不論是差的設計、開發還是錯誤的（開發工具）賣主的選擇。
- 供應商選擇：在你啓動J2EE工程之前，挑選你的最佳工具組合的過程——不論是應用服務器還是咖啡品牌
- 設計：不論是嚴格的瀑布模型還是"code it and see"（試翻譯爲：編碼和運行查看）方式，我對設計都有這樣一個觀點：我做了充分的設計，因此我可以輕鬆的進入開發階段。當我確切知道我在建造什麼和如何建造時，我認爲我的設計階段完成。另外，在進入開發階段之前，我使用設計模板來保證我對我自己問了所有正確的問題並且有了建議的解決方法。然而，我在該階段同樣也不害怕寫代碼；有時，這是回答問題的唯一方式，執行和模塊化（ performance or modularity）。
- 開發：這個階段早期有大量工作要做。選擇好的工具加上一個良好的設計並不總是意味着開發階段會非常順利，但的確會很有用。
- 穩定性/負荷測試：在這個階段，系統架構師和項目管理員將關注系統健壯性和構建質量，如確保系統的關鍵統計——併發用戶數，失敗的情境等。然而，直到這一階段，代碼質量和運行亦不應被忽略。事實上，你不能留一些差的或慢的代碼到健壯性階段來改。
- 存在階段[live]：這並不是真正的項目階段，it's a date set in stone（想了半天也不知道怎麼翻譯:-{）這是關於準備的階段，也是以前的錯誤的鬼怪出沒的地方，不論是差的設計、開發還是錯誤的（開發工具）賣主的選擇。
- 供應商選擇：在你啓動J2EE工程之前，挑選你的最佳工具組合的過程——不論是應用服務器還是咖啡品牌
- 設計：不論是嚴格的瀑布模型還是"code it and see"（試翻譯爲：編碼和運行查看）方式，我對設計都有這樣一個觀點：我做了充分的設計，因此我可以輕鬆的進入開發階段。當我確切知道我在建造什麼和如何建造時，我認爲我的設計階段完成。另外，在進入開發階段之前，我使用設計模板來保證我對我自己問了所有正確的問題並且有了建議的解決方法。然而，我在該階段同樣也不害怕寫代碼；有時，這是回答問題的唯一方式，執行和模塊化（ performance or modularity）。
- 開發：這個階段早期有大量工作要做。選擇好的工具加上一個良好的設計並不總是意味着開發階段會非常順利，但的確會很有用。
- 穩定性/負荷測試：在這個階段，系統架構師和項目管理員將關注系統健壯性和構建質量，如確保系統的關鍵統計——併發用戶數，失敗的情境等。然而，直到這一階段，代碼質量和運行亦不應被忽略。事實上，你不能留一些差的或慢的代碼到健壯性階段來改。
- 存在階段[live]：這並不是真正的項目階段，it's a date set in stone（想了半天也不知道怎麼翻譯:-{）這是關於準備的階段，也是以前的錯誤的鬼怪出沒的地方，不論是差的設計、開發還是錯誤的（開發工具）賣主的選擇。
- 供應商選擇：在你啓動J2EE工程之前，挑選你的最佳工具組合的過程——不論是應用服務器還是咖啡品牌
- 設計：不論是嚴格的瀑布模型還是"code it and see"（試翻譯爲：編碼和運行查看）方式，我對設計都有這樣一個觀點：我做了充分的設計，因此我可以輕鬆的進入開發階段。當我確切知道我在建造什麼和如何建造時，我認爲我的設計階段完成。另外，在進入開發階段之前，我使用設計模板來保證我對我自己問了所有正確的問題並且有了建議的解決方法。然而，我在該階段同樣也不害怕寫代碼；有時，這是回答問題的唯一方式，執行和模塊化（ performance or modularity）。
- 開發：這個階段早期有大量工作要做。選擇好的工具加上一個良好的設計並不總是意味着開發階段會非常順利，但的確會很有用。
- 穩定性/負荷測試：在這個階段，系統架構師和項目管理員將關注系統健壯性和構建質量，如確保系統的關鍵統計——併發用戶數，失敗的情境等。然而，直到這一階段，代碼質量和運行亦不應被忽略。事實上，你不能留一些差的或慢的代碼到健壯性階段來改。
- 存在階段[live]：這並不是真正的項目階段，it's a date set in stone（想了半天也不知道怎麼翻譯:-{）這是關於準備的階段，也是以前的錯誤的鬼怪出沒的地方，不論是差的設計、開發還是錯誤的（開發工具）賣主的選擇。
圖1闡釋了這些項目階段，以及對其有影響的各種因素（尤其是那些“突然的[knock-on]”影響）
|
危機1：沒有理解Java,沒有理解EJB,沒有理解J2EE
好，現在我將其分解成3個小主題來進一步闡釋。
描述：不理解Java
項目階段：開發階段
所牽連的項目階段：設計，穩定階段，存在階段
受影響的系統特性：可維護性，可測量性（scalability）,執行性
徵兆：
- 重複實現已經包含於JDK核心APIs裏的函數功能和類
- 不知道下面所列的任何一項或幾項是什麼和它們能做什麼（下面列出了一些示例）
- 垃圾回收（train, generational, incremental, synchronous, asynchronous）
- 對象什麼時候可以被“垃圾回收”——
- Java裏面繼承特性的使用（及其權衡使用）
- 方法重載
- 爲什麼
java.lang.String（此處替代你自己喜愛的類）似乎性能很差 - 忽略Java引用的語義（與忽略EJB中值的語義相對）
- 對非基本類型（nonprimitives）使用＝＝而不是實現equals()方法
- 在不同平臺上Java線程的進度如何（for example, pre-emptive or not）
- 綠色線程VS本地線程
- 熱點[Hotspot](Hotspot <and why old performance tuning techniques negate Hotspot optimizations>)
- JIT以及什麼時候好的JITs變差（不安裝的Java編譯器並且你的代碼依然運行良好等）
- The Collections API
- RMI
解決辦法：
你需要提高你的Java知識，尤其是瞭解它的優勢和弱點。Java的存在已經遠遠超除了一門語言本身，同樣重要的是理解這平臺（JDK and tools）.具體的，你應當具有做一名Java 程序員的資格（如果你還沒有的話）——你將對你有如此多不瞭解的東西感到喫驚。更進一步，將它作爲你小組的一部分並向其他人推廣，這種方式同樣很有樂趣。更進一步，創建一份郵件列表，專心於Java技術並且保持下去。（我曾工作過的公司都有這些列表，大多數由於不更新而變的岌岌可危）向你的同伴學習——他們是你最好的資源。
注：
如果你或你團隊中的其他成員不理解這門編程語言和這平臺，你又怎麼能期待建造一個成功的企業級Java應用呢？健壯的Java程序員對於EJB和J2EE如果鴨子對於水一般。與之相對，差的沒有經驗的程序員將建造一個質量差的J2EE應用。
描述：不理解EJB
項目階段：設計
所牽涉項目階段：開發，穩定性階段
受影響的系統特性：可維護性
徵兆：
- EJBs在第一次被調用後就不再管了（尤其是處於就緒池[ready pool]的無狀態SESSION BEANS）
- 非重用的（Nonreusable）EJBs
- 相比於容器提供的，開發者不知道可依賴什麼
- 不符合規範的EJBs(fire threads,調用本地庫，試圖完成I/O操作等)
解決：
爲提高你的EJB知識，花一個週末來閱讀EJB規範（1.1規範有314頁）。然後閱讀2.0規範（524頁）來了解爲什麼1.1規範不再適用和2.0規範能帶給你什麼。關注規範中那些能告訴你——應用開發者——什麼是在EJB中合法的行爲的部分。18.1和18.2節是開始的好地方。
注：
不要從你的提供商（指應用服務器或其他開發軟件的提供商——譯者）的眼裏看EJB世界。確保你瞭解符合規範的EJB模型和特殊的實現之間的不同。這將保證在需要時你可以將你的技術帶給你的提供商（或其他版本）。
描述：不理解J2EE
項目階段：設計
所牽涉項目階段：開發
受影響的系統特性：可維護性，可度量性（scalability），執行性
徵兆：
- “什麼都是EJB”的設計
- 手工配置而不是使用容器提供的機制
- 客戶安全實現——J2EE平臺或許是在企業計算中最完全和完整的安全架構，從表現一直到後臺；它全部能力很少被全部使用的
解決：
學習J2EE關鍵組件以及每個組件所能帶來的優勢和劣勢。依次涉及各項服務，此處知識和能力一樣重要。
注：
只有知識能解決這些問題。好的Java 開發者造就好的EJB開發者——一步步地可以完美地成爲J2EE領袖的人。你獲得越多的Java/J2EE知識，你在設計和實現方面的能力越強.Things will start to slot into place for you at design time.(想了半天也不知道怎麼翻譯:-{ )
危機2：過度設計（無論是否是對於EJB）
項目階段：設計
所涉及的項目階段：開發
受影響的系統特性：可維護性，可測量性（scalability），可執行性
徵兆：
- 特大型EJBs
- 開發者無法解釋他們的EJBs做什麼和它們之間的關係
- 不可重用的EJBs,組件，或服務——當它們應該重用時
- 當已經存在的事務可以完成任務時，EJBs 啓動新的事務
- 數據獨立性被設定的太高（爲了安全的目的）
解決：
解決過度設計的方法可以直接從XP（extreme programming）中找到：局部範圍內，設計和編碼實現最小的暴露的[bare minimum]部分來滿足需求，而不要做的過多。當你需要意識到將來的需求，比如平均負載需求和在系統負載頂峯時候的行爲，不要試圖“第二次猜測”[second-guess]系統將來需要成爲的樣子。另外，J2EE平臺爲你定義了特性如可測度性和服務器底層需要捕獲的任務錯誤。
注：
除了上面的解決方式，使用設計模式——它們會顯著的提高你的系統設計。EJB模型本身廣泛地使用設計模式。如，每個EJB裏的Home接口是一個尋找者和工廠模式的例子[Finder and Factory pattern].一個EJB的遠程接口擔當實際bean的實現的代理，也是容器截取調用和提供服務如透明化負載均衡的能力關鍵。忽略設計模式的價值是危險的。
我不斷強調的另一種危險是：爲使用EJB而使用。你的應用的一些部分在不適合被當作EJB模型時候而被設計爲EJB模型，你的整個應用似乎使用EJBs將獲得無限價值。這是極度的過分設計，我曾看到完美的servlet 和 JavaBean 應用在並沒有好的技術方面的原因而使用EJBs時，變的亂七八糟，不得不重新設計。
危機3：未分離表示邏輯和商業邏輯
項目階段：設計
所涉及的項目階段：開發
所影響的系統性能：可維護性，可擴展性，可執行性
症狀：
- 大型且笨拙的JSPs
- 當商業邏輯改變時，你發現你需要編輯JSP文件
- 顯示需求的改變迫使你編輯和重新部署EJBs和後臺組件
解決：
J2EE平臺給你將表示邏輯同導航和控制分離並最終與商業邏輯分離的機會，這被稱爲Model2 結構（參見 Resources ）。如果你已經掉進圈套，一種比較呆板的做法或許有用。你應該至少使 那些大部分自我包含的片斷保持“垂直瘦小”[thin vertical slices](這是說，我如何佈局的一個片斷要同如何更改我的用戶名和密碼分開)。在你係統中使用這種方式來重新組織。
注：
在你的工程中使用一種連接UI框架（如標籤庫）堅固的設計將幫助你避免邏輯分離問題，不要爲你自己需要的GUI框架設計而煩惱，這會爲你帶來諸多執行方面的好處。依次評估每一種框架，然後選擇最適合你的那種。
危機4 ：未在你開發的地方部署
項目階段：開發
所影響的項目階段：穩定階段，並行階段，存在階段
所影響的系統特性：正常的心智（Your sanity）
徵兆：
- 持續多日及1周的向真正應用系統的遷移
- 關於運行期的風險是固有的，伴隨着諸多未測試的不清晰和主要的情節
- 在運行期系統上的數據和開發及穩定期間的數據不相同
- 在開發者機器上無法運行構建[builds]
- 應用的行爲在開發環境、穩定性環境、產品環境不一致
解決：
危機4的解決辦法是將你產品的環境如實地複製到你的開發環境。在你打算放置產品的確切的環境上開發——不要在Red Hat Linux 上用JDK1.3開發，然後卻佈置到 JDK 1.2.2 和 Solaris 7 上。進一步，不要在這個應用服務器上開發卻部署到另外的服務器上。同時，得到你產品的數據庫的數據的大致印象，並且在其上進行測試，不要依賴人工創造的數據。如果產品數據是敏感的[sensitive],減少其敏感性，裝載它。意想不到的產品數據將打破：
- 數據有效性規則
- 已經測試的系統行爲
- 系統組件間的契約（尤其是EJB-EJB和EJB-DB之間）
最壞的情況，每一項均會導致異常，空指針和你以前從未見過的行爲。
注：
開發者經常到穩定階段纔想起安全性（“耶！屏幕正常，讓我們把用戶加爲確認的員工”）。花費同樣的時間來避免這種圈套實現安全性，就像你分離商業邏輯時候做的那樣。
實施是一個複雜的過程，充滿政治問題和技術問題。你將會碰到你不期望的問題；這就是實施的全部。開發環境和穩定性環境給你在實施前犯錯誤和找到問題的空間，利用這點，將減少應用實施過程中你的痛苦和風險。
你經歷的項目越多，你就越容易知道什麼能運行什麼不能，爲你和你的同伴保留一本項目記事本。在實施過程，你的目標應該是同樣的錯誤不犯兩次。
危機5：選擇錯誤的（開發工具）提供商
項目階段：提供商選擇
所牽涉的項目階段:設計，開發，穩定性/負載測試，實施
所影響的系統特性：可測量性，執行性，可維護性，穩定性
徵兆：
- 開發人員花費較長的時間和工具“較勁”[wrestling]，而不是有效的使用它們
- 在執行過程中，重要的系統需要重新設計來避開知道和不知道的bugs
- 不同工具間差的整合性乃至絲毫不能整合（應用服務器和IDE,IDE和調試工具，源代碼控制和構造工具，等等等等）
- 對於IDE，調試器等，開發者簡單的以個人的喜好來選擇或放棄
解決：
爲了避免危機5，你需要一個好的供應商選擇過程。危機10在這裏是適用的。
對於IDEs,唯一的評價方法是去使用它。評價J2EE的唯一的方式是構建一個你的觀念構架中用到的特性的實現。事實上，當你花費3個月開發和投資到一項特殊的培訓的時候，你不會希望在這些工具之間出現BUG.
那麼，當你開發的半路上遇到關於工具集的麻煩的時候怎麼辦？一些工具似乎比其他的更加重要。如果你選擇的應用服務器不適合你的需求，你要接受它並改變規範。如果IDE令人噁心，就設置最小級別的代碼規範（tabs對空格等等），並讓開發者尋找能最大限度提高生產效率的配置。
注：
瞭解最好的供應商和工具作爲一項特殊的任務並非是一個“只做一次”的工作。你需要不斷對市場評估。例如，過去的12個月，我曾用過4個不同的IDE,這取決於我的應用服務器平臺，而不是我是否寫EJB代碼。
危機6：不瞭解你的供應商
項目階段：供應商選擇
所涉及的項目階段：供應商選擇之後的所有階段
受影響的系統特性：可維護性，可測量性，執行性
徵兆：
- 開發時間比最壞的估計時間長33％
- 當供應商或實現提供的功能超出“圈子”[作者使用了 box，不懂——譯者注]時，開發者重新發明輪子。[Developers reinvent the wheel when the vendor or implementation provides the required functionality out of the box]
解決：
爲避免由於不瞭解供應商而產生的問題，去訂閱所有的供應商所能提供的資源，如郵件列表，新聞組，和發行註釋（尤其是那些修訂BUGS的列表）；你將得到無可估量的信息。
一旦你選定了供應商就要馬上投資於培訓，然後，建立一個快速的概念的實現來打破這個它。[Once you've picked your vendors, invest in training as soon as possible, ideally well before the project kicks off. Next, build a quick proof of concept to break the team in gently.原文如此，譯的鬱悶:-{] 建立兩個Ejbs並部署它們，然後通過你的顯示層技術（Swing GUI，Jsps 等）調用它們。如果你試着構造你的開發環境同時試着滿足一個項目目標，環境的設置將不盡人意。事實上，我曾經看到過沒有經過部署過程的項目，原因是“我們沒有時間”。當團隊不得不每天晚上幹到11點僅僅是爲了獲得一個發佈的應用的時候，此處的意義就顯得尤爲重要。因此，事先花費一些時間將這些細節處理好，在以後的路上你將節約大量時間。對那些說“我們的計劃沒有給我們這麼多的時間”的人，我要說，“你的計劃沒有給你不做它的時間。”
注：
在J2EE世界中，工具提供商的技術的可轉換性[transferable]如何呢？讓我們看一看兩個供應商的具體例子——IBM和BEA系統公司——支持EJB1.1的不同的應用服務器。確實，BEA WebLogic 5.1 和 IBM WebSphere 3.5 有多大程度的相似呢？
- BEA WebLogic 的配置管理風格與IBM WebSphere 非常不同。
- IBM對於WEBSPHERE採用了全GUI環境，與此對應，BEA 對於WebLogic提供了全命令行的控制工具。
- IBM WebSphere 對於程序員採用了IIOP 來通訊和拋出CORBA 可見的異常，weblogic根本沒有CORBA 層，默認採用t3協議。
這裏只是幾個不同之處，還有許多。概要：多數的供應商之間的相似就像粉筆和奶油之相似一樣。在一種應用服務器上成爲一名專家並不意味着你在所有的服務器上都是專家。上面的討論適合於任何東西：IDEs,調試器，編譯工具，配置管理等等。對於一種特殊工具擁有使用經驗對於評價其競爭對手是一件好事情。但這並不意味着你可以從一種工具平滑的過度到另一種。儘量給你自己時間來熟悉你的工具。
危機7：沒有爲可測量性或可執行性設計
項目階段：設計
所涉及的項目階段：開發，測試，生存期
受影響的系統特性：可測量性，可執行性，可維護性
徵兆：
- 系統慢的不可接受
- 過度利用服務端狀態的系統及不能充分利用供應商集羣技術
解決：
對於危機7，在分析階段你要明確的知道系統的執行性能和測量性能——在進入開發之前就要知道你需要得到的數字。如果你知道你需要每秒處理50個交易，但所有的實體Bean的設計只能提供40個交易/秒，那麼你需要爲你的系統尋找替代方式，比如存儲過程，批處理或重寫的OLTP 方面[reworked OLTP aspects ].
儘量求助於你的工具供應商——他們應該知道他們產品的優缺點，並因此而幫助你。
注：
沒有爲可測量性或可執行性設計經常和危機2（過度設計）相牴觸。事實上，它們相互取長補短。對於危機2我的解決方式是隻有絕對需要的時候才進行部署。對於確定可測量性和可執行性，你可以在需要的時候設置可能的最大值。
如果你確定大量的測度是一個必需的需求，你可以指定一個支持最大聚合的應用服務器，可能的話，爲你的執行提供一個交易緩存。進一步，你可以設計商業對象如Ejbs來最大程度的利用服務器的架構。XP沒有這樣的問題，你仍然可以在必須的時候再部署.
我回顧這種方式，思考提供這種平衡的方式。當我想一個最簡單的系統時，那個系統需要提供客戶要求的功能和行爲。
危機8：陳舊的開發過程
項目階段：開發
所涉及的項目階段：穩定性，生存期
受影響的系統特性：可維護性和編碼質量
徵兆：
- 一個項目計劃像可疑的瀑布模型：“首先，我們進行整體設計，然後，我們坐下花大量時間來編碼。”
- 由於部署過程不存在，部署便成了一個噩夢。
- 部署的天數等於所花費的開發天數，因爲什麼都沒完成。
- 在整合時組件未經過充分測試。實際上，整體測試意味着將兩個不穩定的組件的綁到一起，然後看它們的堆棧。
解決：
一個好的軟件設計方法將拯救你的生命。我經常提到XP；下面的資源包含一個這樣的鏈接(Resources)。你將發現XP覆蓋了很大的細節。
注：
我並沒有 沒經過Junit單元測試和沒有用Ant部署的經歷——那是兩個可以加強XP方法的免費工具。參見： Resources.
危機9：使用框架失敗
項目階段：開發
所涉及的項目階段：開發過程，穩定性能，生存期
受影響的系統特性：可維護性，可擴展性和編碼質量
徵兆：
- 核心庫中的Bug在代碼裏重複使用
- 沒有設定日誌標準——因此係統的輸出不可讀或不能轉換成scripts
- 差的或不協調的異常處理。在一些站點上我看到，終端用戶在一些低級錯誤上被暴露，例如，當用戶試圖爲購物車結帳的時候出現SQLException的堆棧追蹤。用戶接下來做什麼呢？打電話給數據庫管理員並強制報告這個錯誤嗎？
下面的任務需要開發者在大量的情況下處理，並且，應該作爲使用框架的首要任務：
- 記錄日誌
- 異常處理
- 獲取相關資源的鏈接（數據庫，名字服務等）
- 建立JSP頁面
- 數據有效性驗證
解決：
我對在重型應用中使用輕量級框架堅信不移。事實上，我在JavaWorld的第一篇文章"Frameworks Save the Day" 討論過在企業開發環境中使用框架的問題。如果你現在已經在開發，馬上採用框架仍然將獲得重大收益。你將經歷重新工作的痛苦，像日誌及異常捕獲，但就長遠來看，你會節約大量時間和金錢。
注：
當你採用框架和麪向組件編程時候，考慮不同級別的重用。在第一層，重塑（plumbing），使用0.9或更高的重用因子（reuse factor）,這意味着90％的工程將用到它。越是特殊的服務，其重用因子越低。是說，我可能建立一個帳號服務來管理資源使用，希望50%的工程用到它。但對於那些需要它的工程——那些搞開發的男孩將很高興它在那裏！
危機10：將工程計劃和設計基於市場廣告，而不是技術現實
注：
危機10並未出現在我的列表中，直到我認識到有許多的人而不僅僅是我一個存在對企業java的誤解，尤其是那些新鮮的領域。
項目階段：
所有的項目階段，尤其是供應商的選擇更明顯。
所影響的項目階段：
所有階段
所影響的項目特性：
可維護性，可擴展性，設計質量，代碼質量
徵兆：
- 技術方面的決策佔很輕的分量，因爲EJB被設計的輕便
- 供應商選擇對於產品未經過是否輕便的試驗
- 在項目生存期需要選擇工具
解決：
不要相信在你項目之外的任何既得利益者。這是說：不要相信供應商（除非你已經瞭解他們了），不要相信供應商提供的白紙。如果你想要一些真實的應用服務器的建議，查詢以前的鏈接：Resources。進一步，下載你想評測的工具，挽起袖子，設計原型。通過提供的例子來運行（任何好的提供商都有例子）。
總之，選擇正確的供應商和工具集需要花費時間，儘管你的時間可能並不充裕。將你的選擇集中到3個－4個，然後每個都試一下。花費一週的時間來驗證你的應用服務器，IDE，部署過程等等，直到用這些工具可以滿足你的開發計劃時。
注：
如果你對J2EE不熟悉，在項目開始階段你將很受打擊。一開始所做的決定將對整個項目的成功有巨大的影響。一個好的J2EE顧問可能要進行一個重大的供應商選擇過程並很好地將你帶入設計和開發狀態。
只有這10項危機？
10只是一個武斷的數字，只是作爲一個斷點——還有數不清的其他危機存在。確實，我自己仍知道比這多一倍的危機。即使這樣，如果你防備了這裏所列出的，我保證你的工程可以完美和成功。
如果只從這篇文章中吸取一樣東西，我的建議是：沒有什麼可以替代經驗和計劃的[There is no substitute for experience and planning]。如果你沒有經驗，那麼你去試，然後得到它。在工程過程中，不要將賭注押到工程開始時候你以及你團隊的培訓上。開發前就進行一些編碼，更好的是在設計之前就做編碼。把你的Java和J2EE團隊交給經驗豐富的人來帶以確保整個工程的方向和你團隊中那些經驗少的成員可以沿着這條路成長起來。
最後，我寫的越多，我越清楚我想說的：
- 軟件工程的社會層面
- 單元測試和整體測試（什麼時候測試完成？）
- 設計模式
- 異常捕獲
唉，我沒有那麼多的空間，下一篇文章將很快出來。不論如何，祝好運！
結論
好吧，就這麼多。上面的互相影響的10項危機，是你在企業Java開發中將要面對或已經面對的大多數（如果不是全部的話）問題的原因。自然的，在你的旅途中還會遇到許多問題，但我相信，我已經揭示了最主要的原因。做個回顧，下面就是按重要程度劃分的這10項危機：
- 沒有理解Java,沒有理解EJB,沒有理解J2EE
- 過度設計（無論是否是對於EJB）
- 未分離表示邏輯和商業邏輯
- 未在你開發的地方部署
- 選擇錯誤的（開發工具）提供商
- 不瞭解你的供應商
- 沒有爲可測量性或可執行性設計
- 陳舊的開發過程
- 使用框架失敗
- 將工程計劃和設計基於市場廣告，而不是技術現實