作者：Humphrey Sheil
原文出處：http://java.sun.com/developer/technicalArticles/J2EE/projectdangers/
翻譯：gooing 2005-01-18
http://blog.csdn.net/gooing/
感謝金山詞霸和薛叉叉，請指正!

這篇文章結(jié)構(gòu)簡單，我會按以下方式來揭示各種危機：

• 危機的名稱
• 項目階段（Project phase）：危機所出現(xiàn)的項目階段
• 所牽連的項目階段（Project phase(s) affected）：大多情況下，這些危機對隨后的“項目階段”有一種順帶（knock-on）的影響
• 解決：避免危機的方式以及如何最小化它們的影響
• 注釋：有關(guān)該危機我想透露的觀點，但不適合以前的分類

如上所注，我們將在企業(yè)級JAVA項目背景和它的各個重要階段中檢查每一項危險。這些項目階段包括：

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

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

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

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

圖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

好，現(xiàn)在我將其分解成3個小主題來進一步闡釋。

描述：不理解Java

項目階段：開發(fā)階段

所牽連的項目階段：設(shè)計，穩(wěn)定階段，存在階段

受影響的系統(tǒng)特性：可維護性，可測量性（scalability）,執(zhí)行性

征兆：

• 重復(fù)實現(xiàn)已經(jīng)包含于JDK核心APIs里的函數(shù)功能和類

• 不知道下面所列的任何一項或幾項是什么和它們能做什么（下面列出了一些示例）

  　

  • 垃圾回收（train, generational, incremental, synchronous, asynchronous）
  • 對象什么時候可以被“垃圾回收”——
  • Java里面繼承特性的使用（及其權(quán)衡使用）
  • 方法重載
  • 為什么java.lang.String（此處替代你自己喜愛的類）似乎性能很差
  • 忽略Java引用的語義（與忽略EJB中值的語義相對）
  • 對非基本類型（nonprimitives）使用＝＝而不是實現(xiàn)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知識，尤其是了解它的優(yōu)勢和弱點。Java的存在已經(jīng)遠遠超除了一門語言本身，同樣重要的是理解這平臺（JDK and tools）.具體的，你應(yīng)當(dāng)具有做一名Java 程序員的資格（如果你還沒有的話）——你將對你有如此多不了解的東西感到吃驚。更進一步，將它作為你小組的一部分并向其他人推廣，這種方式同樣很有樂趣。更進一步，創(chuàng)建一份郵件列表，專心于Java技術(shù)并且保持下去。（我曾工作過的公司都有這些列表，大多數(shù)由于不更新而變的岌岌可危）向你的同伴學(xué)習(xí)——他們是你最好的資源。

注：

如果你或你團隊中的其他成員不理解這門編程語言和這平臺，你又怎么能期待建造一個成功的企業(yè)級Java應(yīng)用呢？健壯的Java程序員對于EJB和J2EE如果鴨子對于水一般。與之相對，差的沒有經(jīng)驗的程序員將建造一個質(zhì)量差的J2EE應(yīng)用。

描述：不理解EJB

項目階段：設(shè)計

所牽涉項目階段：開發(fā)，穩(wěn)定性階段

受影響的系統(tǒng)特性：可維護性

征兆：

• EJBs在第一次被調(diào)用后就不再管了（尤其是處于就緒池[ready pool]的無狀態(tài)SESSION BEANS）
• 非重用的（Nonreusable）EJBs
• 相比于容器提供的，開發(fā)者不知道可依賴什么
• 不符合規(guī)范的EJBs(fire threads,調(diào)用本地庫，試圖完成I/O操作等)

解決：

為提高你的EJB知識，花一個周末來閱讀EJB規(guī)范（1.1規(guī)范有314頁）。然后閱讀2.0規(guī)范（524頁）來了解為什么1.1規(guī)范不再適用和2.0規(guī)范能帶給你什么。關(guān)注規(guī)范中那些能告訴你——應(yīng)用開發(fā)者——什么是在EJB中合法的行為的部分。18.1和18.2節(jié)是開始的好地方。

注：

不要從你的提供商（指應(yīng)用服務(wù)器或其他開發(fā)軟件的提供商——譯者）的眼里看EJB世界。確保你了解符合規(guī)范的EJB模型和特殊的實現(xiàn)之間的不同。這將保證在需要時你可以將你的技術(shù)帶給你的提供商（或其他版本）。

描述：不理解J2EE    

項目階段：設(shè)計

所牽涉項目階段：開發(fā)

受影響的系統(tǒng)特性：可維護性，可度量性（scalability），執(zhí)行性

征兆：

• “什么都是EJB”的設(shè)計
• 手工配置而不是使用容器提供的機制
• 客戶安全實現(xiàn)——J2EE平臺或許是在企業(yè)計算中最完全和完整的安全架構(gòu)，從表現(xiàn)一直到后臺；它全部能力很少被全部使用的

解決：

學(xué)習(xí)J2EE關(guān)鍵組件以及每個組件所能帶來的優(yōu)勢和劣勢。依次涉及各項服務(wù)，此處知識和能力一樣重要。

注：

只有知識能解決這些問題。好的Java 開發(fā)者造就好的EJB開發(fā)者——一步步地可以完美地成為J2EE領(lǐng)袖的人。你獲得越多的Java/J2EE知識，你在設(shè)計和實現(xiàn)方面的能力越強.Things will start to slot into place for you at design time.(想了半天也不知道怎么翻譯:-{ )

危機2：過度設(shè)計（無論是否是對于EJB）

項目階段：設(shè)計

所涉及的項目階段：開發(fā)

受影響的系統(tǒng)特性：可維護性，可測量性（scalability），可執(zhí)行性

征兆：

• 特大型EJBs
• 開發(fā)者無法解釋他們的EJBs做什么和它們之間的關(guān)系
• 不可重用的EJBs,組件，或服務(wù)——當(dāng)它們應(yīng)該重用時
• 當(dāng)已經(jīng)存在的事務(wù)可以完成任務(wù)時，EJBs 啟動新的事務(wù)
• 數(shù)據(jù)獨立性被設(shè)定的太高（為了安全的目的）

解決：
解決過度設(shè)計的方法可以直接從XP（extreme programming）中找到：局部范圍內(nèi)，設(shè)計和編碼實現(xiàn)最小的暴露的[bare minimum]部分來滿足需求，而不要做的過多。當(dāng)你需要意識到將來的需求，比如平均負載需求和在系統(tǒng)負載頂峰時候的行為，不要試圖“第二次猜測”[second-guess]系統(tǒng)將來需要成為的樣子。另外，J2EE平臺為你定義了特性如可測度性和服務(wù)器底層需要捕獲的任務(wù)錯誤。

注：

除了上面的解決方式，使用設(shè)計模式——它們會顯著的提高你的系統(tǒng)設(shè)計。EJB模型本身廣泛地使用設(shè)計模式。如，每個EJB里的Home接口是一個尋找者和工廠模式的例子[Finder and Factory pattern].一個EJB的遠程接口擔(dān)當(dāng)實際bean的實現(xiàn)的代理，也是容器截取調(diào)用和提供服務(wù)如透明化負載均衡的能力關(guān)鍵。忽略設(shè)計模式的價值是危險的。

我不斷強調(diào)的另一種危險是：為使用EJB而使用。你的應(yīng)用的一些部分在不適合被當(dāng)作EJB模型時候而被設(shè)計為EJB模型，你的整個應(yīng)用似乎使用EJBs將獲得無限價值。這是極度的過分設(shè)計，我曾看到完美的servlet 和 JavaBean 應(yīng)用在并沒有好的技術(shù)方面的原因而使用EJBs時，變的亂七八糟，不得不重新設(shè)計。

危機3：未分離表示邏輯和商業(yè)邏輯

項目階段：設(shè)計

所涉及的項目階段：開發(fā)

所影響的系統(tǒng)性能：可維護性，可擴展性，可執(zhí)行性

癥狀：

• 大型且笨拙的JSPs
• 當(dāng)商業(yè)邏輯改變時，你發(fā)現(xiàn)你需要編輯JSP文件
• 顯示需求的改變迫使你編輯和重新部署EJBs和后臺組件

解決：

J2EE平臺給你將表示邏輯同導(dǎo)航和控制分離并最終與商業(yè)邏輯分離的機會，這被稱為Model2 結(jié)構(gòu)（參見 Resources ）。如果你已經(jīng)掉進圈套，一種比較呆板的做法或許有用。你應(yīng)該至少使 那些大部分自我包含的片斷保持“垂直瘦小”[thin vertical slices](這是說，我如何布局的一個片斷要同如何更改我的用戶名和密碼分開)。在你系統(tǒng)中使用這種方式來重新組織。

注：

在你的工程中使用一種連接UI框架（如標簽庫）堅固的設(shè)計將幫助你避免邏輯分離問題，不要為你自己需要的GUI框架設(shè)計而煩惱，這會為你帶來諸多執(zhí)行方面的好處。依次評估每一種框架，然后選擇最適合你的那種。

危機4 ：未在你開發(fā)的地方部署

項目階段：開發(fā)

所影響的項目階段：穩(wěn)定階段，并行階段，存在階段

所影響的系統(tǒng)特性：正常的心智（Your sanity）

征兆：

• 持續(xù)多日及1周的向真正應(yīng)用系統(tǒng)的遷移
• 關(guān)于運行期的風(fēng)險是固有的，伴隨著諸多未測試的不清晰和主要的情節(jié)
• 在運行期系統(tǒng)上的數(shù)據(jù)和開發(fā)及穩(wěn)定期間的數(shù)據(jù)不相同
• 在開發(fā)者機器上無法運行構(gòu)建[builds]
• 應(yīng)用的行為在開發(fā)環(huán)境、穩(wěn)定性環(huán)境、產(chǎn)品環(huán)境不一致

解決：

危機4的解決辦法是將你產(chǎn)品的環(huán)境如實地復(fù)制到你的開發(fā)環(huán)境。在你打算放置產(chǎn)品的確切的環(huán)境上開發(fā)——不要在Red Hat Linux 上用JDK1.3開發(fā)，然后卻布置到 JDK 1.2.2 和 Solaris 7 上。進一步，不要在這個應(yīng)用服務(wù)器上開發(fā)卻部署到另外的服務(wù)器上。同時，得到你產(chǎn)品的數(shù)據(jù)庫的數(shù)據(jù)的大致印象，并且在其上進行測試，不要依賴人工創(chuàng)造的數(shù)據(jù)。如果產(chǎn)品數(shù)據(jù)是敏感的[sensitive],減少其敏感性，裝載它。意想不到的產(chǎn)品數(shù)據(jù)將打破：

• 數(shù)據(jù)有效性規(guī)則
• 已經(jīng)測試的系統(tǒng)行為
• 系統(tǒng)組件間的契約（尤其是EJB-EJB和EJB-DB之間）

最壞的情況，每一項均會導(dǎo)致異常，空指針和你以前從未見過的行為。

注：

開發(fā)者經(jīng)常到穩(wěn)定階段才想起安全性（“耶！屏幕正常，讓我們把用戶加為確認的員工”）?；ㄙM同樣的時間來避免這種圈套實現(xiàn)安全性，就像你分離商業(yè)邏輯時候做的那樣。

實施是一個復(fù)雜的過程，充滿政治問題和技術(shù)問題。你將會碰到你不期望的問題；這就是實施的全部。開發(fā)環(huán)境和穩(wěn)定性環(huán)境給你在實施前犯錯誤和找到問題的空間，利用這點，將減少應(yīng)用實施過程中你的痛苦和風(fēng)險。

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

危機5：選擇錯誤的（開發(fā)工具）提供商

項目階段：提供商選擇

所牽涉的項目階段:設(shè)計，開發(fā)，穩(wěn)定性/負載測試，實施

所影響的系統(tǒng)特性：可測量性，執(zhí)行性，可維護性，穩(wěn)定性

征兆：

• 開發(fā)人員花費較長的時間和工具“較勁”[wrestling]，而不是有效的使用它們
• 在執(zhí)行過程中，重要的系統(tǒng)需要重新設(shè)計來避開知道和不知道的bugs
• 不同工具間差的整合性乃至絲毫不能整合（應(yīng)用服務(wù)器和IDE,IDE和調(diào)試工具，源代碼控制和構(gòu)造工具，等等等等）
• 對于IDE，調(diào)試器等，開發(fā)者簡單的以個人的喜好來選擇或放棄

解決：

為了避免危機5，你需要一個好的供應(yīng)商選擇過程。危機10在這里是適用的。

對于IDEs,唯一的評價方法是去使用它。評價J2EE的唯一的方式是構(gòu)建一個你的觀念構(gòu)架中用到的特性的實現(xiàn)。事實上，當(dāng)你花費3個月開發(fā)和投資到一項特殊的培訓(xùn)的時候，你不會希望在這些工具之間出現(xiàn)BUG.

那么，當(dāng)你開發(fā)的半路上遇到關(guān)于工具集的麻煩的時候怎么辦？一些工具似乎比其他的更加重要。如果你選擇的應(yīng)用服務(wù)器不適合你的需求，你要接受它并改變規(guī)范。如果IDE令人惡心，就設(shè)置最小級別的代碼規(guī)范（tabs對空格等等），并讓開發(fā)者尋找能最大限度提高生產(chǎn)效率的配置。

注：

了解最好的供應(yīng)商和工具作為一項特殊的任務(wù)并非是一個“只做一次”的工作。你需要不斷對市場評估。例如，過去的12個月，我曾用過4個不同的IDE,這取決于我的應(yīng)用服務(wù)器平臺，而不是我是否寫EJB代碼。

危機6：不了解你的供應(yīng)商

項目階段：供應(yīng)商選擇

所涉及的項目階段：供應(yīng)商選擇之后的所有階段

受影響的系統(tǒng)特性：可維護性，可測量性，執(zhí)行性

征兆：

• 開發(fā)時間比最壞的估計時間長33％
• 當(dāng)供應(yīng)商或?qū)崿F(xiàn)提供的功能超出“圈子”[作者使用了 box，不懂——譯者注]時，開發(fā)者重新發(fā)明輪子。[Developers reinvent the wheel when the vendor or implementation provides the required functionality out of the box]

解決：

為避免由于不了解供應(yīng)商而產(chǎn)生的問題，去訂閱所有的供應(yīng)商所能提供的資源，如郵件列表，新聞組，和發(fā)行注釋（尤其是那些修訂BUGS的列表）；你將得到無可估量的信息。

一旦你選定了供應(yīng)商就要馬上投資于培訓(xùn)，然后，建立一個快速的概念的實現(xiàn)來打破這個它。[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并部署它們，然后通過你的顯示層技術(shù)（Swing GUI，Jsps 等）調(diào)用它們。如果你試著構(gòu)造你的開發(fā)環(huán)境同時試著滿足一個項目目標，環(huán)境的設(shè)置將不盡人意。事實上，我曾經(jīng)看到過沒有經(jīng)過部署過程的項目，原因是“我們沒有時間”。當(dāng)團隊不得不每天晚上干到11點僅僅是為了獲得一個發(fā)布的應(yīng)用的時候，此處的意義就顯得尤為重要。因此，事先花費一些時間將這些細節(jié)處理好，在以后的路上你將節(jié)約大量時間。對那些說“我們的計劃沒有給我們這么多的時間”的人，我要說，“你的計劃沒有給你不做它的時間?！?/P>

注：　

在J2EE世界中，工具提供商的技術(shù)的可轉(zhuǎn)換性[transferable]如何呢？讓我們看一看兩個供應(yīng)商的具體例子——IBM和BEA系統(tǒng)公司——支持EJB1.1的不同的應(yīng)用服務(wù)器。確實，BEA WebLogic 5.1 和 IBM WebSphere 3.5 有多大程度的相似呢？

1. BEA WebLogic 的配置管理風(fēng)格與IBM WebSphere 非常不同。
2. IBM對于WEBSPHERE采用了全GUI環(huán)境，與此對應(yīng)，BEA 對于WebLogic提供了全命令行的控制工具。
3. IBM WebSphere 對于程序員采用了IIOP 來通訊和拋出CORBA 可見的異常，weblogic根本沒有CORBA 層，默認采用t3協(xié)議。

這里只是幾個不同之處，還有許多。概要：多數(shù)的供應(yīng)商之間的相似就像粉筆和奶油之相似一樣。在一種應(yīng)用服務(wù)器上成為一名專家并不意味著你在所有的服務(wù)器上都是專家。上面的討論適合于任何東西：IDEs,調(diào)試器，編譯工具，配置管理等等。對于一種特殊工具擁有使用經(jīng)驗對于評價其競爭對手是一件好事情。但這并不意味著你可以從一種工具平滑的過度到另一種。盡量給你自己時間來熟悉你的工具。

危機7：沒有為可測量性或可執(zhí)行性設(shè)計

項目階段：設(shè)計

所涉及的項目階段：開發(fā)，測試，生存期

受影響的系統(tǒng)特性：可測量性，可執(zhí)行性，可維護性

征兆：

• 系統(tǒng)慢的不可接受
• 過度利用服務(wù)端狀態(tài)的系統(tǒng)及不能充分利用供應(yīng)商集群技術(shù)

解決：

對于危機7，在分析階段你要明確的知道系統(tǒng)的執(zhí)行性能和測量性能——在進入開發(fā)之前就要知道你需要得到的數(shù)字。如果你知道你需要每秒處理50個交易，但所有的實體Bean的設(shè)計只能提供40個交易/秒，那么你需要為你的系統(tǒng)尋找替代方式，比如存儲過程，批處理或重寫的OLTP 方面[reworked OLTP aspects ].

盡量求助于你的工具供應(yīng)商——他們應(yīng)該知道他們產(chǎn)品的優(yōu)缺點，并因此而幫助你。

注：

沒有為可測量性或可執(zhí)行性設(shè)計經(jīng)常和危機2（過度設(shè)計）相抵觸。事實上，它們相互取長補短。對于危機2我的解決方式是只有絕對需要的時候才進行部署。對于確定可測量性和可執(zhí)行性，你可以在需要的時候設(shè)置可能的最大值。

如果你確定大量的測度是一個必需的需求，你可以指定一個支持最大聚合的應(yīng)用服務(wù)器，可能的話，為你的執(zhí)行提供一個交易緩存。進一步，你可以設(shè)計商業(yè)對象如Ejbs來最大程度的利用服務(wù)器的架構(gòu)。XP沒有這樣的問題，你仍然可以在必須的時候再部署.

我回顧這種方式，思考提供這種平衡的方式。當(dāng)我想一個最簡單的系統(tǒng)時，那個系統(tǒng)需要提供客戶要求的功能和行為。

危機8：陳舊的開發(fā)過程

項目階段：開發(fā)

所涉及的項目階段：穩(wěn)定性，生存期

受影響的系統(tǒng)特性：可維護性和編碼質(zhì)量

征兆：

• 一個項目計劃像可疑的瀑布模型：“首先，我們進行整體設(shè)計，然后，我們坐下花大量時間來編碼。”
• 由于部署過程不存在，部署便成了一個噩夢。
• 部署的天數(shù)等于所花費的開發(fā)天數(shù)，因為什么都沒完成。
• 在整合時組件未經(jīng)過充分測試。實際上，整體測試意味著將兩個不穩(wěn)定的組件的綁到一起，然后看它們的堆棧。

解決：
一個好的軟件設(shè)計方法將拯救你的生命。我經(jīng)常提到XP；下面的資源包含一個這樣的鏈接(Resources)。你將發(fā)現(xiàn)XP覆蓋了很大的細節(jié)。

注：
我并沒有 沒經(jīng)過Junit單元測試和沒有用Ant部署的經(jīng)歷——那是兩個可以加強XP方法的免費工具。參見： Resources.

危機9：使用框架失敗

項目階段：開發(fā)

所涉及的項目階段：開發(fā)過程，穩(wěn)定性能，生存期

受影響的系統(tǒng)特性：可維護性，可擴展性和編碼質(zhì)量

征兆：

• 核心庫中的Bug在代碼里重復(fù)使用
• 沒有設(shè)定日志標準——因此系統(tǒng)的輸出不可讀或不能轉(zhuǎn)換成scripts
• 差的或不協(xié)調(diào)的異常處理。在一些站點上我看到，終端用戶在一些低級錯誤上被暴露，例如，當(dāng)用戶試圖為購物車結(jié)帳的時候出現(xiàn)SQLException的堆棧追蹤。用戶接下來做什么呢？打電話給數(shù)據(jù)庫管理員并強制報告這個錯誤嗎？

下面的任務(wù)需要開發(fā)者在大量的情況下處理，并且，應(yīng)該作為使用框架的首要任務(wù)：

• 記錄日志
• 異常處理
• 獲取相關(guān)資源的鏈接（數(shù)據(jù)庫，名字服務(wù)等）
• 建立JSP頁面
• 數(shù)據(jù)有效性驗證

解決：

我對在重型應(yīng)用中使用輕量級框架堅信不移。事實上，我在JavaWorld的第一篇文章"Frameworks Save the Day" 討論過在企業(yè)開發(fā)環(huán)境中使用框架的問題。如果你現(xiàn)在已經(jīng)在開發(fā)，馬上采用框架仍然將獲得重大收益。你將經(jīng)歷重新工作的痛苦，像日志及異常捕獲，但就長遠來看，你會節(jié)約大量時間和金錢。

注：

當(dāng)你采用框架和面向組件編程時候，考慮不同級別的重用。在第一層，重塑（plumbing），使用0.9或更高的重用因子（reuse factor）,這意味著90％的工程將用到它。越是特殊的服務(wù)，其重用因子越低。是說，我可能建立一個帳號服務(wù)來管理資源使用，希望50%的工程用到它。但對于那些需要它的工程——那些搞開發(fā)的男孩將很高興它在那里！

危機10：將工程計劃和設(shè)計基于市場廣告，而不是技術(shù)現(xiàn)實

注：

危機10并未出現(xiàn)在我的列表中，直到我認識到有許多的人而不僅僅是我一個存在對企業(yè)java的誤解，尤其是那些新鮮的領(lǐng)域。

項目階段：
所有的項目階段，尤其是供應(yīng)商的選擇更明顯。

所影響的項目階段：
所有階段

所影響的項目特性：
可維護性，可擴展性，設(shè)計質(zhì)量，代碼質(zhì)量

征兆：

• 技術(shù)方面的決策占很輕的分量，因為EJB被設(shè)計的輕便
• 供應(yīng)商選擇對于產(chǎn)品未經(jīng)過是否輕便的試驗
• 在項目生存期需要選擇工具

解決：

不要相信在你項目之外的任何既得利益者。這是說：不要相信供應(yīng)商（除非你已經(jīng)了解他們了），不要相信供應(yīng)商提供的白紙。如果你想要一些真實的應(yīng)用服務(wù)器的建議，查詢以前的鏈接：Resources。進一步，下載你想評測的工具，挽起袖子，設(shè)計原型。通過提供的例子來運行（任何好的提供商都有例子）。

總之，選擇正確的供應(yīng)商和工具集需要花費時間，盡管你的時間可能并不充裕。將你的選擇集中到3個－4個，然后每個都試一下?；ㄙM一周的時間來驗證你的應(yīng)用服務(wù)器，IDE，部署過程等等，直到用這些工具可以滿足你的開發(fā)計劃時。

注：
如果你對J2EE不熟悉，在項目開始階段你將很受打擊。一開始所做的決定將對整個項目的成功有巨大的影響。一個好的J2EE顧問可能要進行一個重大的供應(yīng)商選擇過程并很好地將你帶入設(shè)計和開發(fā)狀態(tài)。

只有這10項危機？

10只是一個武斷的數(shù)字，只是作為一個斷點——還有數(shù)不清的其他危機存在。確實，我自己仍知道比這多一倍的危機。即使這樣，如果你防備了這里所列出的，我保證你的工程可以完美和成功。

如果只從這篇文章中吸取一樣?xùn)|西，我的建議是：沒有什么可以替代經(jīng)驗和計劃的[There is no substitute for experience and planning]。如果你沒有經(jīng)驗，那么你去試，然后得到它。在工程過程中，不要將賭注押到工程開始時候你以及你團隊的培訓(xùn)上。開發(fā)前就進行一些編碼，更好的是在設(shè)計之前就做編碼。把你的Java和J2EE團隊交給經(jīng)驗豐富的人來帶以確保整個工程的方向和你團隊中那些經(jīng)驗少的成員可以沿著這條路成長起來。

最后，我寫的越多，我越清楚我想說的：

• 軟件工程的社會層面
• 單元測試和整體測試（什么時候測試完成？）
• 設(shè)計模式
• 異常捕獲

唉，我沒有那么多的空間，下一篇文章將很快出來。不論如何，祝好運！

結(jié)論

好吧，就這么多。上面的互相影響的10項危機，是你在企業(yè)Java開發(fā)中將要面對或已經(jīng)面對的大多數(shù)（如果不是全部的話）問題的原因。自然的，在你的旅途中還會遇到許多問題，但我相信，我已經(jīng)揭示了最主要的原因。做個回顧，下面就是按重要程度劃分的這10項危機：

1. 沒有理解Java,沒有理解EJB,沒有理解J2EE
2. 過度設(shè)計（無論是否是對于EJB）
3. 未分離表示邏輯和商業(yè)邏輯
4. 未在你開發(fā)的地方部署
5. 選擇錯誤的（開發(fā)工具）提供商
6. 不了解你的供應(yīng)商
7. 沒有為可測量性或可執(zhí)行性設(shè)計
8. 陳舊的開發(fā)過程
9. 使用框架失敗
10. 將工程計劃和設(shè)計基于市場廣告，而不是技術(shù)現(xiàn)實