J2EE項目開發風險

時間：2024-08-03 07:43:58 J2EE培訓

J2EE項目開發風險匯總

　　在各種各樣的風險中，有些風險只是延緩了項目的進度，有些帶來了一些不必要的工作，而另一些則會把成功的可能性徹底地消除。下面小編總結了J2EE項目開發的風險，提供給大家參考!

　　風險1:沒有真正理解 Java, EJB, 和J2EE

　　這個問題可以分解為3個部分，以便于分析。

　　描述: 沒有真正理解Java

　　項目階段:開發

　　影響階段：設計、穩定性測試、成熟期

　　對系統性能的影響：可維護性、可擴展性、性能

　　癥狀：

　　重復開發了JDK核心API中的功能或類

　　不懂得以下列表中的某些項(這只是一些主題或者實際例子而已)：

　　垃圾收集器 (train, generational, incremental, synchronous, asynchronous)

　　對象在何時能被進行垃圾收集 dangling references

　　使用的繼承機制及其權衡

　　overriding和overloading方法

　　為什么java.lang.String (在這里用你所中意的類代替) 提供的性能不好

　　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等。

　　風險6: 不了解你的提供商

　　項目階段：

　　提供商選擇

　　影響階段:

　　提供商選擇階段后面的所有階段：設計、開發、穩定化/負載測試、成熟化

　　對系統的影響:

　　可維護性、可伸縮性、性能

　　癥狀:

　　開發所用周期超過了最壞預測的周期1/3以上

　　提供商已經提供了某項功能，但開發者在不知道的情況下重新進行了該項功能的開發

　　規避方案:

　　為了規避這樣的風險，你可以盡可能地訂閱提供商的網上資源，例如郵件列表、新聞組、版本信息(尤其是其中的bug修復補丁的說明等)，你能從中得到無法估量之多的收獲。

　　一旦你已經選定了提供商，那么立即就要投資進行培訓，并且盡可能趕在項目啟動以前。然后，逐漸在團隊中建立起對此提供商的認識及信任。試著建立幾個EJB并部署一下，再用你的表示層技術 (Swing GUI, JSP等)來調用它們。如果你既要搭建開發環境，又要同時在實現項目目標，就會產生一些不必要的沖突。實際上，我也見到過一直沒有進行構建過程的情況：“我們沒有時間。”因此，這些工作必須提早進行。有些人會說：“我們的計劃中沒有為我們提供這些時間。”我的回答是：“你的計劃中并沒有不給你時間使你不這么做啊。”

　　備注:

　　在J2EE世界里，各提供商產品的技術兼容性究竟如何?讓我們看一下IBM和BEA的具體分析吧。兩者都分別在各自的應用服務器中支持EJB 1.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協議。

　　WebSphere和Visual Age銜接緊密，而WebLogic是IDE無關的，實際上，你幾乎可以使用任何的開發工具。

　　由此可見，差異還是相當多。如果你是一種應用服務器的專家，并不意味著你就是所有應用服務器的專家。這種區別體現在IDE，debugger，build工具，配置管理等等方面。具備某提供商的某項特殊工具的使用經驗，可以在評估該提供商的競爭對手產品時具有一些便利。但是，不要奢望在不同產品之間進行無縫的轉移或銜接。因此，你不得不花費足夠多的時間在熟練掌握這些工具上。

　　風險7: 設計中沒有充分考慮到可伸縮性和產品性能

　　項目階段：

　　設計

　　受影響的項目階段:

　　開發、負載測試及成熟化

　　對系統的影響:

　　可伸縮性、性能、可維護性

　　癥狀:

　　無法忍受的速度緩慢

　　系統給服務器端增加的沉重負擔，而無法利用到一些聚簇技術。

　　規避方案:

　　把精力集中于性能和可伸縮性方面的需求，明確開發中要達到的性能指標。如果你需要每秒50個事務，而你的EJB設計只能提供40個，那么你就需要考慮替代方案，諸如存儲過程，批處理，或者重新考慮OLTP的設計。

　　盡可能讓你的提供商加入進來，他們應該非常清楚其產品的強項和弱處在哪里，然后給你提供最直接的幫助。

　　備注:

　　本風險與風險2 (overengineering)似乎有些沖突。實際上，兩者相互影響。我對風險2給出的解決方案是，只在絕對必要的情況下才進行構建。而對與性能和可伸縮性，你要預先劃分好什么是必須要做的。

　　如果你實現就識別出系統需要非常強的可伸縮性，并把它作為一個比較關鍵的需求，那么你首先需要選擇一個帶有很強的簇支持及事務型緩存的應用服務器。另外，你應把業務對象設計為EJB，從而可以充分利用服務器架構的優勢。 XP也沒有問題，你仍然是只做絕對必要的工作。

　　我把這樣的觀點看作是一種檢查和平衡的方法。我們只需要最簡單可能性的系統，該系統只提供客戶所需要的功能與行為即可。

　　風險8: 陳舊的開發過程

　　項目階段：

　　開發

　　影響階段:

　　穩定化，成熟化

　　對系統的影響:

　　可維護性、代碼質量

　　癥狀:

　　項目計劃看上去似乎類似于瀑布模型: “首先草構設計，然后在一個很長的周期里進行開發。”

　　由于不存在構建(build)過程，每次構建都象是噩夢

　　構建的日期等于損失開發的日期，因為什么也沒有做成

　　在集成以前組件沒有分別被充分地測試過，而集成測試意味著將2個不穩定的組件放在一起，然后查看堆棧里的跟蹤結果。

　　規避方案:

　　好的軟件方法學將提高你的軟件生命期。此前我已經提到XP方法，你可以在網上找到很多這方面的資料。

　　備注:

　　JUnit可以用來進行單元測試，Ant工具可以進行編譯與構建，這2種工具都對XP方法有很好的支持。

　　風險9: 沒有好的架構方式

　　項目階段：

　　開發

　　影響階段:

　　開發、穩定化、成熟期

　　對系統的影響：

　　可維護性、可伸縮性、代碼質量

　　癥狀:

　　在代碼中使用了很多次的核心庫中發現Bug。

　　沒有建立日志標準于是系統的輸出很難讀取或者解析。

　　不良的不一致的異常處理。在有些站點中我們甚至可以看到，出錯信息直接暴露給了最終用戶，例如在用戶在他的購物車核帳時發送一條SQLException堆棧跟蹤信息，用戶接著會怎么做?打電話給數據庫管理員要求對primary key約束進行修補嗎?

　　以下任務已經被開發者以各種方式處理了無數次了，這些都有必要放在任何構架設計的第一批目標中。

　　日志

　　異常處理

　　與資源的連接(數據庫，名字服務等)

　　構建JSP頁

　　數據合法性檢查

　　規避方案:

　　我是一個輕方法學的信徒和實踐者。我在JavaWorld 上的第一篇文章 "Frameworks Save the Day" 就是研討在企業Java環境中的架構。即使你已經開始開發了，此時考慮一下架構仍然是值得的。可能你不得不忍受一下重構帶來的異常處理和日志處理，但從長遠來看還是值得的，這樣即省時間又省錢。

　　備注:

　　讓我們想一下在構架中基于組件開發的可重用性的不同等級。第一級別是plumbing，具有0.9以上的可重用比例，也就是說，有90%的項目可以對它重復利用。服務定義得越詳細，重用比例就越低。換句話說，我需要構建一個會計服務，但要提供這些資源與用法的管理，以便于其它50%項目中可以對它們進行重復利用。但是對那些項目來說，能得到這些資源，那真是太好了!

　　風險10: 項目計劃和設計基于市場效應，而脫離了技術現實

　　備注: 不斷有新人加入到Java/EJB的開發領域中來，不理解Java的人數一般比想象中還要多。

　　項目階段：

　　所有階段都會受到影響，包括提供商的選擇

　　影響階段:

　　所有階段都會受到影響

　　對系統的影響:

　　可維護性、可擴展性、設計質量、代碼質量

　　癥狀:

　　輕率地進行技術決策，認為EJB只是為了便攜式處理的方便

　　選擇提供商的時候沒有隨即進行產品的試用

　　在項目的生命周期內還需要更換工具