- 相關(guān)推薦
J2EE項目開發(fā)10大風險盤點
當你開始著手組織一個企業(yè)級Java項目的時候，就如同開始同時輪回地扔好幾個魔術(shù)小球： 業(yè)主關(guān)系處理、持續(xù)而漫長的設(shè)計開發(fā)過程，以及保持健全與完整性，等等。每一個“小球”都會帶來其固有的風險，有些顯而易見，有些則不易發(fā)現(xiàn)。盡管如此，所有這些風險都是完全可以避免的。下面yjbys為大家準備了一篇分析了威脅到企業(yè)級Java項目成功的10大風險， 并一一列出了風險規(guī)避的策略方法。
在過去這段時期里，我擔任過程序員、高級設(shè)計師以及架構(gòu)設(shè)計師等工作，見識過很優(yōu)秀的企業(yè)級Java項目，也見識過不好的，甚至很"丑陋"的項目。有時候我會自己問自己，為什么一個項目可以取得成功，而另一個卻走向失敗?很難定義出某種規(guī)則或標準來表明各個不同的項目應(yīng)該如何成功，J2EE項目也并不例外。但與此相反的是，我們可以從各個角度和層次上去考察項目失敗的原因，如果很好地避開了這些風險，項目就可以取得成功。在本文中，我將提出排名前10位的企業(yè)級Java項目風險，供讀者參考。
在各種各樣的風險中，有些風險只是延緩了項目的進度，有些帶來了一些不必要的工作，而另一些則會把成功的可能性徹底地消除。不過，如果預(yù)先有了足夠的準備和清醒的認識，那么并沒有不可避免的事情。這好比如果你是一名旅行者，你清楚地知道前面的道路在什么方向，做了充分的準備，又有一位清楚知道哪里有危險的向?qū)В@樣就會比較順利地到達自己的目的地。
本文采用了以下結(jié)構(gòu)來描述風險：
風險名稱：風險的標題(使用粗體)
項目階段：在哪個項目階段會發(fā)生風險情況
影響階段：會影響到以后的哪些階段
癥狀： 風險產(chǎn)生時的癥狀
規(guī)避方案：如何規(guī)避風險或者把其對項目的影響降低到最小程度
備注： 風險相關(guān)的補充說明和提示
通過對企業(yè)級Java項目的仔細考察，本文將J2EE項目過程分解為以下幾個階段：
·提供商選擇: 在開始你的J2EE項目之前，要選擇最合適的提供商，從應(yīng)用服務(wù)器到開發(fā)工具組合，一直至工作期間享用的咖啡的廠商。
·設(shè)計： 在遵照一系列嚴格的規(guī)范和軟件工程方法的前提下，可以開始進行足夠充分的設(shè)計，然后再很自然地進入開發(fā)階段。在開發(fā)之前，要周全地考慮好正在做什么，以及如何往下做的問題。另外，我使用了一些設(shè)計模板來確信在進入開發(fā)之前，已經(jīng)想到了所有的問題和可能的解決方案。但是，我有時也在該階段做一些編碼，有時候這樣做可以回答一些問題，有效地判斷出性能上和模塊劃分上的問題。
·開發(fā): 也就是程序開發(fā)階段，選擇一些好的開發(fā)工具，進行精良的設(shè)計等等，在這個階段將顯示其優(yōu)越性，并且可以給開發(fā)帶來很大的幫助。
·穩(wěn)定性/負載測試：在該階段，系統(tǒng)架構(gòu)師和項目經(jīng)理應(yīng)該凍結(jié)住產(chǎn)品特性，并把焦點放在質(zhì)量以及產(chǎn)品參數(shù)(允許的并發(fā)用戶數(shù)量，故障恢復(fù)情況，等等)上。質(zhì)量和性能在該階段應(yīng)得到足夠的重視。當然，最好應(yīng)該避免在前階段寫出不良的運行緩慢的代碼而到本階段來作很多的修改。
·成熟期：這不是一個真正的項目階段，而是一個固定的準備階段。過去潛伏的錯誤(來自于糟糕的設(shè)計和開發(fā)、錯誤的廠商選擇)可能出現(xiàn)并影響你的系統(tǒng)。
OK，以下讓我們進入 top 10 項目風險!
--------------------------------------------------------------------------------
風險1:沒有真正理解 Java, EJB, 和J2EE
這個問題可以分解為3個部分，以便于分析。
描述: 沒有真正理解Java
項目階段:開發(fā)
影響階段：設(shè)計、穩(wěn)定性測試、成熟期
對系統(tǒng)性能的影響：可維護性、可擴展性、性能
癥狀：
重復(fù)開發(fā)了JDK核心API中的功能或類
不懂得以下列表中的某些項(這只是一些主題或者實際例子而已)：
垃圾收集器 (train, generational, incremental, synchronous, asynchronous)
對象在何時能被進行垃圾收集 -- dangling references
使用的繼承機制及其權(quán)衡
over-riding和over-loading方法
為什么java.lang.String (在這里用你所中意的類代替) 提供的性能不好
Java中的pass-by參考語義和EJB中pass-by值的語義的比較
使用 == 或者使用equals() 方法 for nonprimitives
在不同平臺上Java線程的運行順序方式(例如是否是搶先方式的)
新線程和本地線程的比較
Hotspot技術(shù)(以及為什么舊的性能調(diào)整技術(shù)降低了Hotspot 的優(yōu)化效果)
JIT，以及什么時候好的JIT變得不好(未安裝的JAVA編譯器，以及你的代碼運行得剛夠良好)
API搜集
RMI
規(guī)避方案：
你需要不斷改進Java方面的知識，尤其是深入了解Java的優(yōu)勢和不足之處。Java的存在價值已經(jīng)遠不止是一種語言，理解平臺(JDK及工具等)也是同樣重要的。具體地說，你應(yīng)該是經(jīng)過認證的Java程序員，如果你不是的話，也許你有時會為還有那么多不知道的內(nèi)容而感到驚訝。另外，你可以加入Java的郵件列表。以前我曾加盟過的每一個公司都加入了這樣的郵件列表，從同行中學(xué)到技術(shù)，這將是你最好的資源。
備注:
如果你或者你的團隊中的成員不真正了解編程語言和平臺，怎么還能保持成功的希望呢?強干的Java程序員之于EJB和J2EE，就象是鴨子之于水一樣。與此相反，比較弱的、沒有經(jīng)驗的程序員只能開發(fā)出質(zhì)量低劣的J2EE應(yīng)用程序。
描述: 沒有真正理解EJB
項目階段:
設(shè)計
影響階段:
開發(fā)、穩(wěn)定化
對系統(tǒng)的影響:
維護
癥狀:
EJB在第一次被調(diào)用后沒有再被使用到(尤其是stateless session bean)
沒有重復(fù)利用價值的EJB
不理解開發(fā)者要做什么，容器提供什么
EJB沒有依照規(guī)范定義(fire線程, 加載了本地庫，試圖執(zhí)行I/O，等等)
解決方案:
要改進關(guān)于EJB方面的知識，可以找一個周末來閱讀EJB規(guī)范 (1.1版有314頁)，然后閱讀2.0規(guī)范(524頁!)，這樣可以了解到1.1沒有定義到的而在2.0規(guī)范中補充的內(nèi)容。EJB開發(fā)者從18.1及18.2章節(jié)開始閱讀是比較合適的。
備注:
不要從提供商的角度去看EJB，要確切地知道規(guī)范所支持的標準EJB模型和基于這些模型的特殊應(yīng)用之間的區(qū)別。這也會有助于你遷移到別的提供商的時候所用。
描述: 沒有真正理解J2EE
項目階段:
設(shè)計
影響階段:
開發(fā)
對系統(tǒng)的影響:
維護、擴展性、性能
癥狀:
"Everything is an EJB"的設(shè)計方式
用手工事務(wù)管理取代了容器-提供的機制
自定義方式的安全處理 -- J2EE平臺在企業(yè)級計算中，從表示邏輯到后臺處理，已具有最完整的集成安全架構(gòu);但很少用到其全部功能。
解決方案:
學(xué)習J2EE的關(guān)鍵組件，并且了解它們的優(yōu)缺點，依次用它們替代每一個服務(wù);“知識就是力量”在這里是行之有效的。
備注:
只有知識能夠彌補這些問題。好的Java開發(fā)者會成為好的EJB開發(fā)者，此后也應(yīng)逐漸成為J2EE得道高手。Java和J2EE知識掌握得越多，設(shè)計和開發(fā)工作就會越出色。在設(shè)計階段一切都會有條不紊。
--------------------------------------------------------------------------------
風險2: 過度設(shè)計(Over-engineering) (采用 EJB或者不采用EJB)
項目階段：
設(shè)計
影響的項目階段:
開發(fā)
對系統(tǒng)的影響:
維護、擴展性、性能
癥狀:
過于龐大的EJB
開發(fā)者無法解釋EJB做什么，以及其間的聯(lián)系
無法重復(fù)使用的EJB、組件或者服務(wù)
EJB啟動了新的事務(wù)，而該事務(wù)本該由一個已存在的EJB啟動
為了安全，把數(shù)據(jù)分離級別定得太高
解決方案:
過度工程化的解決之道直接來自于極限編程 (XP)方法：用最小的設(shè)計和編程來滿足需求，除此之外別無它干。除非你需要明確知道今后可能的需求，如將來的負載要求，或者系統(tǒng)在最高負載下的表現(xiàn)，否則大可不必為系統(tǒng)將來的情況做太多考慮或猜測。另外，J2EE平臺已經(jīng)定義了可伸縮性及出錯恢復(fù)等特性，可以讓服務(wù)器系統(tǒng)為你進行處理。
在最小的系統(tǒng)中，只包含一個個小組件，這些組件只做一件事，只要把這些要求做到的進行實現(xiàn)，系統(tǒng)穩(wěn)定性就已經(jīng)得到了提高，而且，你的系統(tǒng)的可維護性會變得很強，在未來要增加功能以滿足新的需求也將變得容易。
備注:
除了上面所列方案之外，可以推行設(shè)計模式 -- 它們可以顯著地改進你的系統(tǒng)設(shè)計。EJB模型本身也廣泛使用了設(shè)計模式。例如，每個EJB所帶的Home 接口就是Finder和Factory模式的實例。EJB的remote接口扮演了一種實際bean實現(xiàn)的代理，并且對于提供容器的能力也是至關(guān)重要的，這些容器截取調(diào)用信號并提供諸如透明(transparent)負載均衡的服務(wù)。忽視設(shè)計模式也是危險的一部分。
我常提到要反對的另外一種危險是：僅僅是為了使用EJB而使用EJB。在你的應(yīng)用中的某一部分可能并不需要EJB，甚至你的整個應(yīng)用都不需要。這是過度工程化所走的極端，而且我確實也目睹了一些良好的servlet和JavaBean應(yīng)用被重構(gòu)為EJB，而這樣做并沒有很好的技術(shù)上的理由。
--------------------------------------------------------------------------------
風險3: 沒有將業(yè)務(wù)規(guī)則和邏輯表現(xiàn)形式相分離
項目階段：
設(shè)計
影響的項目階段：
開發(fā)
對系統(tǒng)的影響:
維護、擴展性、性能
癥狀:
過于龐大、沒有邊際的JSP程序
在業(yè)務(wù)邏輯改變的時候必須修改JSP
在要求改變界面顯示的時候需要修改并重新配置EJB和其它后臺組件
規(guī)避方案:
J2EE平臺使你有機會將表示邏輯和導(dǎo)航控制相分離，進而與業(yè)務(wù)規(guī)則相分離。這被稱為模式2結(jié)構(gòu)。
備注:
可以使用具有一致性的設(shè)計來進行用戶界面框架的連接。(例如可以使用taglib)，這將幫助你避免邏輯分離的問題。有許多現(xiàn)成的好的方法可供選擇。對每一個分別進行評估，然后采用最合適的框架。
--------------------------------------------------------------------------------
風險4: 沒有在開發(fā)環(huán)境中進行適當?shù)呐渲?/strong>
項目階段：
開發(fā)
影響的項目階段:
穩(wěn)定化、并發(fā)、成熟期
對系統(tǒng)的影響:
你的權(quán)衡
癥狀:
經(jīng)過多日或數(shù)周的時間才能過渡到成熟系統(tǒng)
風險存在與過渡期，帶有很多不確定性，有些主要的功能場景沒有被測試到
實際系統(tǒng)中的數(shù)據(jù)和開發(fā)、測試中的數(shù)據(jù)不同
無法在開發(fā)者機器上進行組建
應(yīng)用行為在開發(fā)、穩(wěn)定化及產(chǎn)品環(huán)境中各不相同
規(guī)避方案:
解決之道是忠實地在開發(fā)環(huán)境中配置實際的環(huán)境，讓開發(fā)所用環(huán)境接近于要實施產(chǎn)品的環(huán)境。如果未來環(huán)境是JDK 1.2.2及Solaris 7，那么不要在JDK 1.3及Red Hat Linux上進行開發(fā)。對于所用的應(yīng)用服務(wù)器也是如此。同樣，要快速地看一下產(chǎn)品數(shù)據(jù)庫中的數(shù)據(jù)，并將這樣的數(shù)據(jù)用于測試。不要依賴于人工創(chuàng)建的數(shù)據(jù)。如果產(chǎn)品數(shù)據(jù)很敏感，則要使之變得不敏感，然后把它配置起來。開發(fā)中未能預(yù)期到的產(chǎn)品數(shù)據(jù)將對以下過程產(chǎn)生破壞：
數(shù)據(jù)檢驗規(guī)則
系統(tǒng)測試行為
系統(tǒng)組件構(gòu)建(特別地包括：EJB-EJB以及EJB-數(shù)據(jù)庫)
最為糟糕的是，這樣還可能產(chǎn)生異常、空指針，以及你從沒見過的問題。
備注:
開發(fā)人員常把安全性問題放到穩(wěn)定化階段才開始解決。要防止這樣的陷阱產(chǎn)生，你也可以花費同樣多的時間在業(yè)務(wù)邏輯中改進安全性。
成熟期是一個復(fù)雜的過程，其中充滿了技術(shù)性問題和非技術(shù)性問題。你可能會陷于想不到的一大堆問題中，這就是成熟化所意味的一切。開發(fā)及穩(wěn)定化環(huán)境過程為你提供了制造更多這樣的問題，以及發(fā)現(xiàn)這樣的問題的地方，不斷去做，就可以大大減少風險。
你做的工程越多，你就越能了解什么是可行的，什么是不可行的。你可以對工程問題進行記錄，以避免同樣的錯誤重復(fù)發(fā)生。
--------------------------------------------------------------------------------
風險5: 選擇了錯誤的提供商
項目階段：
提供商選擇
影響階段：
設(shè)計、開發(fā)、穩(wěn)定化/負載測試，成熟化
對系統(tǒng)的影響:
可伸縮性、性能、可維護性及穩(wěn)定性
癥狀:
開發(fā)人員要使用更多的時間來處理工具方面的問題，而不是很有成效地使用這些工具
為了應(yīng)付已知的和未知的問題，而不得不進行顯著的系統(tǒng)重新設(shè)計
在不同的工具之間很難進行集成(應(yīng)用服務(wù)器與IDE工具，IDE工具與調(diào)試器，源碼控制與合成工具，等等)
對于IDE工具和調(diào)試器等，開發(fā)人員往往排斥它們，而推崇自己所喜歡的工具
規(guī)避方案:
為了避免風險5，你需要一個很好的提供商選擇過程，風險10的規(guī)避也適用于此。
要真正衡量一種IDE工具是否最合適的方法是真正地進行使用。而唯一來評估一種J2EE應(yīng)用的方法是建立一種概念試驗來進行證明，在試驗中要包含你的應(yīng)用框架。事實上，你也不希望在花費了3個月時間進行了培訓(xùn)和開發(fā)后，在使用時又發(fā)現(xiàn)一些bug。
假設(shè)在開發(fā)到一半的時候，突然發(fā)現(xiàn)你的工具集有問題，那么你早應(yīng)該知道，有些工具確實比另一些更重要。如果你所選的應(yīng)用服務(wù)器不能充分滿足你的需要，你只好修改原先的設(shè)定。如果IDE不好，則需要設(shè)置最低限度的代碼標準，并讓開發(fā)人員任意選擇他們認為最為有效的工具。
備注:
要真正了解到哪一個供應(yīng)商對一項特殊的任務(wù)來說最合適，其實并不是一件一次性決定的事情。你需要不斷地跟蹤與評估這個市場。例如，在過去的一年里我用過4種不同的IDE工具，這取決于我使用了什么樣的應(yīng)用服務(wù)器、平臺，是否使用EJB等。
--------------------------------------------------------------------------------
風險6: 不了解你的提供商
項目階段：
提供商選擇
影響階段:
提供商選擇階段后面的所有階段：設(shè)計、開發(fā)、穩(wěn)定化/負載測試、成熟化
對系統(tǒng)的影響:
可維護性、可伸縮性、性能
癥狀:
開發(fā)所用周期超過了最壞預(yù)測的周期1/3以上
提供商已經(jīng)提供了某項功能，但開發(fā)者在不知道的情況下重新進行了該項功能的開發(fā)
規(guī)避方案:
為了規(guī)避這樣的風險，你可以盡可能地訂閱提供商的網(wǎng)上資源，例如郵件列表、新聞組、版本信息(尤其是其中的bug修復(fù)補丁的說明等)，你能從中得到無法估量之多的收獲。
一旦你已經(jīng)選定了提供商，那么立即就要投資進行培訓(xùn)，并且盡可能趕在項目啟動以前。然后，逐漸在團隊中建立起對此提供商的認識及信任。試著建立幾個EJB并部署一下，再用你的表示層技術(shù) (Swing GUI, JSP等)來調(diào)用它們。如果你既要搭建開發(fā)環(huán)境，又要同時在實現(xiàn)項目目標，就會產(chǎn)生一些不必要的沖突。實際上，我也見到過一直沒有進行構(gòu)建過程的情況：“我們沒有時間。”因此，這些工作必須提早進行。有些人會說：“我們的計劃中沒有為我們提供這些時間。”我的回答是：“你的計劃中并沒有不給你時間使你不這么做啊。”
備注:
在J2EE世界里，各提供商產(chǎn)品的技術(shù)兼容性究竟如何?讓我們看一下IBM和BEA的具體分析吧。兩者都分別在各自的應(yīng)用服務(wù)器中支持EJB 1.1。那么，實際上BEA WebLogic 5.1和IBM WebSphere 3.5究竟有多少相似之處呢?
BEA WebLogic和IBM WebSphere的系統(tǒng)配置和管理方式幾乎完全不同。
IBM在WebSphere中采用了全面的GUI環(huán)境，而與之相對的是，BEA 在WebLogic中提供一整套命令行。
IBM WebSphere使用IIOP來和CORBA異常進行通訊，這些異常對程序員來說是可見的;WebLogic根本沒有CORBA構(gòu)造，而缺省使用t3協(xié)議。
WebSphere和Visual Age銜接緊密，而WebLogic是IDE無關(guān)的，實際上，你幾乎可以使用任何的開發(fā)工具。
由此可見，差異還是相當多。如果你是一種應(yīng)用服務(wù)器的專家，并不意味著你就是所有應(yīng)用服務(wù)器的專家。這種區(qū)別體現(xiàn)在IDE，debugger，build工具，配置管理等等方面。具備某提供商的某項特殊工具的使用經(jīng)驗，可以在評估該提供商的競爭對手產(chǎn)品時具有一些便利。但是，不要奢望在不同產(chǎn)品之間進行無縫的轉(zhuǎn)移或銜接。因此，你不得不花費足夠多的時間在熟練掌握這些工具上。
--------------------------------------------------------------------------------
風險7: 設(shè)計中沒有充分考慮到可伸縮性和產(chǎn)品性能
項目階段：
設(shè)計
受影響的項目階段:
開發(fā)、負載測試及成熟化
對系統(tǒng)的影響:
可伸縮性、性能、可維護性
癥狀:
無法忍受的速度緩慢
系統(tǒng)給服務(wù)器端增加的沉重負擔，而無法利用到一些聚簇技術(shù)。
規(guī)避方案:
把精力集中于性能和可伸縮性方面的需求，明確開發(fā)中要達到的性能指標。如果你需要每秒50個事務(wù)，而你的EJB設(shè)計只能提供40個，那么你就需要考慮替代方案，諸如存儲過程，批處理，或者重新考慮OLTP的設(shè)計。
盡可能讓你的提供商加入進來，他們應(yīng)該非常清楚其產(chǎn)品的強項和弱處在哪里，然后給你提供最直接的幫助。
備注:
本風險與風險2 (over-engineering)似乎有些沖突。實際上，兩者相互影響。 我對風險2給出的解決方案是，只在絕對必要的情況下才進行構(gòu)建。而對與性能和可伸縮性，你要預(yù)先劃分好什么是必須要做的。
如果你實現(xiàn)就識別出系統(tǒng)需要非常強的可伸縮性，并把它作為一個比較關(guān)鍵的需求，那么你首先需要選擇一個帶有很強的簇支持及事務(wù)型緩存的應(yīng)用服務(wù)器。另外，你應(yīng)把業(yè)務(wù)對象設(shè)計為EJB，從而可以充分利用服務(wù)器架構(gòu)的優(yōu)勢。 XP也沒有問題，你仍然是只做絕對必要的工作。
我把這樣的觀點看作是一種檢查和平衡的方法。我們只需要最簡單可能性的系統(tǒng)，該系統(tǒng)只提供客戶所需要的功能與行為即可。
--------------------------------------------------------------------------------
風險8: 陳舊的開發(fā)過程
項目階段：
開發(fā)
影響階段:
穩(wěn)定化，成熟化
對系統(tǒng)的影響:
可維護性、代碼質(zhì)量
癥狀:
項目計劃看上去似乎類似于瀑布模型: “首先草構(gòu)設(shè)計，然后在一個很長的周期里進行開發(fā)。”
由于不存在構(gòu)建(build)過程，每次構(gòu)建都象是噩夢
構(gòu)建的日期等于損失開發(fā)的日期，因為什么也沒有做成
在集成以前組件沒有分別被充分地測試過，而集成測試意味著將2個不穩(wěn)定的組件放在一起，然后查看堆棧里的跟蹤結(jié)果。
規(guī)避方案:
好的軟件方法學(xué)將提高你的軟件生命期。此前我已經(jīng)提到XP方法，你可以在網(wǎng)上找到很多這方面的資料。
備注:
JUnit可以用來進行單元測試，Ant工具可以進行編譯與構(gòu)建，這2種工具都對XP方法有很好的支持。
--------------------------------------------------------------------------------
風險9: 沒有好的架構(gòu)方式
項目階段：
開發(fā)
影響階段:
開發(fā)、穩(wěn)定化、成熟期
對系統(tǒng)的影響：
可維護性、可伸縮性、代碼質(zhì)量
癥狀:
在代碼中使用了很多次的核心庫中發(fā)現(xiàn)Bug。
沒有建立日志標準 -- 于是系統(tǒng)的輸出很難讀取或者解析。
不良的不一致的異常處理。在有些站點中我們甚至可以看到，出錯信息直接暴露給了最終用戶，例如在用戶在他的購物車核帳時發(fā)送一條SQLException堆棧跟蹤信息，用戶接著會怎么做?打電話給數(shù)據(jù)庫管理員要求對primary key約束進行修補嗎?
以下任務(wù)已經(jīng)被開發(fā)者以各種方式處理了無數(shù)次了，這些都有必要放在任何構(gòu)架設(shè)計的第一批目標中。
日志
異常處理
與資源的連接(數(shù)據(jù)庫，名字服務(wù)等)
構(gòu)建JSP頁
數(shù)據(jù)合法性檢查
規(guī)避方案:
我是一個輕方法學(xué)的信徒和實踐者。我在JavaWorld 上的第一篇文章 -- "Frameworks Save the Day" -- 就是研討在企業(yè)Java環(huán)境中的架構(gòu)。即使你已經(jīng)開始開發(fā)了，此時考慮一下架構(gòu)仍然是值得的�？赡苣悴坏貌蝗淌芤幌轮貥�(gòu)帶來的異常處理和日志處理，但從長遠來看還是值得的，這樣即省時間又省錢。
備注:
讓我們想一下在構(gòu)架中基于組件開發(fā)的可重用性的不同等級。第一級別是plumbing，具有0.9以上的可重用比例，也就是說，有90%的項目可以對它重復(fù)利用。 服務(wù)定義得越詳細，重用比例就越低。換句話說，我需要構(gòu)建一個會計服務(wù)，但要提供這些資源與用法的管理，以便于其它50%項目中可以對它們進行重復(fù)利用。但是對那些項目來說，能得到這些資源，那真是太好了!
--------------------------------------------------------------------------------
風險10: 項目計劃和設(shè)計基于市場效應(yīng)，而脫離了技術(shù)現(xiàn)實
備注: 不斷有新人加入到Java/EJB的開發(fā)領(lǐng)域中來，不理解Java的人數(shù)一般比想象中還要多。
項目階段：
所有階段都會受到影響，包括提供商的選擇
影響階段:
所有階段都會受到影響
對系統(tǒng)的影響:
可維護性、可擴展性、設(shè)計質(zhì)量、代碼質(zhì)量
癥狀:
輕率地進行技術(shù)決策，認為EJB只是為了便攜式處理的方便
選擇提供商的時候沒有隨即進行產(chǎn)品的試用
在項目的生命周期內(nèi)還需要更換工具
規(guī)避方案:
不要輕易相信項目外部的任何人的看法，這些人可能已經(jīng)有一些既得利益，不要相信提供商的說法(除非你早已經(jīng)了解)，也不要相信白皮書。如果你要取得來自真實世界的關(guān)于應(yīng)用服務(wù)器的建議，可以在網(wǎng)上取得。你還可以下載這些工具進行評估，用它們做一些原型，并運行一下其中的樣例。(好的提供商都有這樣的樣例)。
總的來說，為你的項目選擇最好的提供商及工具需要時間，而你可能沒有太多的時間。你可以把選擇范圍限制在3-4個對象，然后用一周時間進行比較和檢驗。最后從中選出比較滿意的工具和產(chǎn)品。
備注:
如果你缺少J2EE經(jīng)驗，則可能會在項目前期就產(chǎn)生問題。在前期所確定的決策會影響整個過程，并進而影響項目的成功。好的J2EE咨詢專家將能夠幫助你選擇好的提供商，并為設(shè)計和開發(fā)刻劃出一個好的構(gòu)形。
--------------------------------------------------------------------------------
僅僅只有這10項風險嗎?
10只是一個特定的數(shù)字，顯然，還有更多更多的風險會存在。只是我可以保證的是，如果你克服了所列的各項風險，那么你的項目會有出色的表現(xiàn)并已打好了成功的基礎(chǔ)。
還有一項需要注意，即沒有任何東西可以代替經(jīng)驗和計劃。如果你沒有經(jīng)驗，那么一定要想辦法取得并積累。千萬不要一邊做項目一邊進行培訓(xùn)。在開發(fā)之前要預(yù)先做好充分的準備，最好是在設(shè)計以前就進行準備。可以讓你的團隊接受Java/J2EE顧問的指導(dǎo)，并確保這樣的指導(dǎo)能夠傳遞到整個其他的團隊成員。
【J2EE項目開發(fā)10大風險盤點】相關(guān)文章：
J2EE項目開發(fā)風險匯總08-03
Eclipse j2ee開發(fā)環(huán)境的搭建12-26
Java Web開發(fā)和J2EE的區(qū)別07-07
J2EE項目中的異常處理01-22
J2EE項目代碼編寫規(guī)范01-23
J2EE開發(fā)使用手冊目錄09-25
J2EE軟件開發(fā)過程10-24
j2ee應(yīng)用技術(shù)開發(fā)結(jié)構(gòu)10-21
項目采購風險管理的探究05-30