J2EE項目危機【翻譯】 -避免這10項J2EE危機來確保你的企業JAVA項目成功

j2ee|項目  

在我作為開發人員、進階開發人員、架構師的經曆中，我遇到過好的、差的甚至是醜陋的企業級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（想了半天也不知道怎麼翻譯:-{）這是關於準備的階段，也是以前的錯誤的鬼怪出沒的地方，不論是差的設計、開發還是錯誤的（開發工具）賣主的選擇。

• 供應商選擇：在你啟動J2EE工程之前，挑選你的最佳工具組合的過程——不論是應用伺服器還是咖啡品牌
• 設計：不論是嚴格的瀑布模型還是"code it and see"（試翻譯為：編碼和運行查看）方式，我對設計都有這樣一個觀點：我做了充分的設計，因此我可以輕鬆的進入開發階段。當我確切知道我在建造什麼和如何建造時，我認為我的設計階段完成。另外，在進入開發階段之前，我使用設計範本來保證我對我自己問了所有正確的問題並且有了建議的解決方案。然而，我在該階段同樣也不害怕寫代碼；有時，這是回答問題的唯一方式，執行和模組化（ performance or modularity）。
• 開發：這個階段早期有大量工作要做。選擇好的工具加上一個良好的設計並不總是意味著開發階段會非常順利，但的確會很有用。
• 穩定性/負荷測試：在這個階段，系統架構師和專案系統管理員將關注系統健壯性和構建品質，如確保系統的關鍵統計——並發使用者數，失敗的情境等。然而，直到這一階段，代碼品質和運行亦不應被忽略。事實上，你不能留一些差的或慢的代碼到健壯性階段來改。
• 存在階段[live]：這並不是真正的項目階段，it's a date set in stone（想了半天也不知道怎麼翻譯:-{）這是關於準備的階段，也是以前的錯誤的鬼怪出沒的地方，不論是差的設計、開發還是錯誤的（開發工具）賣主的選擇。

圖1闡釋了這些項目階段，以及對其有影響的各種因素（尤其是那些“突然的[knock-on]”影響）

　

Figure 1. Enterprise Java project phases
and their most likely reasons for failure.
Click on thumbnail to view full-size
image. (60 KB)

危機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之間）

最壞的情況，每一項均會導致異常，null 指標和你以前從未見過的行為。

註：

開發人員經常到穩定階段才想起安全性（“耶！螢幕正常，讓我們把使用者加為確認的員工”）。花費同樣的時間來避免這種圈套實現安全性，就像你分離商業邏輯時候做的那樣。

實施是一個複雜的過程，充滿政治問題和技術問題。你將會碰到你不期望的問題；這就是實施的全部。開發環境和穩定性環境給你在實施前犯錯誤和找到問題的空間，利用這點，將減少應用實施過程中你的痛苦和風險。

你經曆的項目越多，你就越容易知道什麼能運行什麼不能，為你和你的同伴保留一本項目記事本。在實施過程，你的目標應該是同樣的錯誤不犯兩次。

　

危機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 有多大程度的相似呢？

1. BEA WebLogic 的組態管理風格與IBM WebSphere 非常不同。
2. IBM對於WEBSPHERE採用了全GUI環境，與此對應，BEA 對於WebLogic提供了全命令列的控制工具。
3. 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項危機：

1. 沒有理解Java,沒有理解EJB,沒有理解J2EE
2. 過度設計（無論是否是對於EJB）
3. 未分離表示邏輯和商業邏輯
4. 未在你開發的地方部署
5. 選擇錯誤的（開發工具）供應商
6. 不瞭解你的供應商
7. 沒有為可測量性或可執行性設計
8. 陳舊的開發過程
9. 使用架構失敗
10. 將工程計劃和設計基於市場廣告，而不是技術現實