1、.：.；J2EE開發工程10大風險總結當他開場著手組織一個企業級Java工程的時候，就好像開場同時輪回地扔好幾個魔術小球：業主關系處置、繼續而漫長的設計開發過程，以及堅持健全與完好性，等等。每一個“小球都會帶來其固有的風險，有些顯而易見，有些那么不易發現。雖然如此，一切這些風險都是完全可以防止的。本文作者HumphreySheil分析了要挾到企業級Java工程勝利的10大風險，并一一列出了風險躲避的戰略方法。在過去這段時期里，我擔任過程序員、高級設計師以及架構設計師等任務，見識過很優秀的企業級Java工程，也見識過不好的，甚至很丑陋的工程。有時候我會本人問本人，為什么一個工程可以獲得勝利，而另

2、一個卻走向失敗？很難定義出某種規那么或規范來闡明各個不同的工程應該如何勝利，J2EE工程也并不例外。但與此相反的是，我們可以從各個角度和層次上去調查工程失敗的緣由，假設很好地避開了這些風險，工程就可以獲得勝利。在本文中，我將提出排名前10位的企業級Java工程風險，供讀者參考。在各種各樣的風險中，有些風險只是延緩了工程的進度，有些帶來了一些不用要的任務，而另一些那么會把勝利的能夠性徹底地消除。不過，假設預先有了足夠的預備和清醒的認識，那么并沒有不可防止的事情。這好比假設他是一名游覽者，他清楚地知道前面的道路在什么方向，做了充分的預備，又有一位清楚知道哪里有危險的導游，這樣就會比較順利地到達本人

3、的目的地。本文采用了以下構造來描畫風險：風險稱號：風險的標題運用粗體工程階段：在哪個工程階段會發生風險情況影響階段：會影響到以后的哪些階段病癥：風險產生時的病癥躲避方案：如何躲避風險或者把其對工程的影響降低到最小程度備注：風險相關的補充闡明和提示經過對企業級Java工程的仔細調查，本文將J2EE工程過程分解為以下幾個階段：提供商選擇:在開場他的J2EE工程之前，要選擇最適宜的提供商，從運用效力器到開發工具組合，不斷至任務期間享用的咖啡的廠商。設計：在遵照一系列嚴厲的規范和軟件工程方法的前提下，可以開場進展足夠充分的設計，然后再很自然地進入開發階段。在開發之前，要周全地思索好正在做什么，以及如何

4、往下做的問題。另外，我運用了一些設計模板來確信在進入開發之前，曾經想到了一切的問題和能夠的處理方案。但是，我有時也在該階段做一些編碼，有時候這樣做可以回答一些問題，有效地判別出性能上和模塊劃分上的問題。開發:也就是程序開發階段，選擇一些好的開發工具，進展精良的設計等等，在這個階段將顯示其優越性，并且可以給開發帶來很大的協助 。穩定性/負載測試：在該階段，系統架構師和工程經理應該凍結住產品特性，并把焦點放在質量以及產品參數允許的并發用戶數量，缺點恢復情況，等等上。質量和性能在該階段應得到足夠的注重。當然，最好應該防止在前階段寫出不良的運轉緩慢的代碼而到本階段來作很多的修正。成熟期：這不是一個真正

5、的工程階段，而是一個固定的預備階段。過去埋伏的錯誤于糟糕的設計和開發、錯誤的廠商選擇能夠出現并影響他的系統。風險1:沒有真正了解Java,EJB,和J2EE這個問題可以分解為3個部分，以便于分析。描畫:沒有真正了解Java工程階段:開發影響階段：設計、穩定性測試、成熟期對系統性能的影響：可維護性、可擴展性、性能病癥：反復開發了JDK中心API中的功能或類不懂得以以下表中的某些項這只是一些主題或者實踐例子而已：渣滓搜集器(train,generational,incremental,synchronous,asynchronous)對象在何時能被進展渣滓搜集-danglingreferences

6、運用的承繼機制及其權衡over-riding和over-loading方法為什么java.lang.String(在這里用他所中意的類替代)提供的性能不好Java中的pass-by參考語義和EJB中pass-by值的語義的比較運用=或者運用equals()方法fornonprimitives在不同平臺上Java線程的運轉順序方式(例如能否是搶先方式的)新線程和本地線程的比較Hotspot技術(以及為什么舊的性能調整技術降低了Hotspot的優化效果)JIT，以及什么時候好的JIT變得不好(未安裝的JAVA編譯器，以及他的代碼運轉得剛夠良好)API搜集RMI躲避方案：他需求不斷改良Java方面的

7、知識，尤其是深化了解Java的優勢和缺乏之處。Java的存在價值曾經遠不止是一種言語，了解平臺(JDK及工具等)也是同樣重要的。詳細地說，他應該是經過認證的Java程序員，假設他不是的話，也許他有時會為還有那么多不知道的內容而感到詫異。另外，他可以參與Java的郵件列表。以前我曾加盟過的每一個公司都參與了這樣的郵件列表，從同行中學到技術，這將是他最好的資源。備注:假設他或者他的團隊中的成員不真正了解編程言語和平臺，怎樣還能堅持勝利的希望呢？強干的Java程序員之于EJB和J2EE，就象是鴨子之于水一樣。與此相反，比較弱的、沒有閱歷的程序員只能開發出質量低劣的J2EE運用程序。描畫:沒有真正了解

8、EJB工程階段:設計影響階段:開發、穩定化對系統的影響:維護病癥:EJB在第一次被調用后沒有再被運用到(尤其是statelesssessionbean)沒有反復利用價值的EJB不了解開發者要做什么，容器提供什么EJB沒有按照規范定義(fire線程,加載了本地庫，試圖執行I/O，等等)處理方案:要改良關于EJB方面的知識，可以找一個周末來閱讀EJB規范(1.1版有314頁)，然后閱讀2.0規范(524頁!)，這樣可以了解到1.1沒有定義到的而在2.0規范中補充的內容。EJB開發者從18.1及18.2章節開場閱讀是比較適宜的。備注:不要從提供商的角度去看EJB，要確切地知道規范所支持的規范EJB模

9、型和基于這些模型的特殊運用之間的區別。這也會有助于他遷移到別的提供商的時候所用。描畫:沒有真正了解J2EE工程階段:設計影響階段:開發對系統的影響:維護、擴展性、性能病癥:EverythingisanEJB的設計方式用手工事務管理取代了容器-提供的機制自定義方式的平安處置-J2EE平臺在企業級計算中，從表示邏輯到后臺處置，已具有最完好的集成平安架構；但很少用到其全部功能。處理方案:學習J2EE的關鍵組件，并且了解它們的優缺陷，依次用它們替代每一個效力；“知識就是力量在這里是行之有效的。備注:只需知識可以彌補這些問題。好的Java開發者會成為好的EJB開發者，以后也應逐漸成為J2EE得道高手。J

10、ava和J2EE知識掌握得越多，設計和開發任務就會越出色。在設計階段一切都會有條不紊。風險2:過度設計(Over-engineering)(采用EJB或者不采用EJB)工程階段：設計影響的工程階段:開發對系統的影響:維護、擴展性、性能病癥:過于龐大的EJB開發者無法解釋EJB做什么，以及其間的聯絡無法反復運用的EJB、組件或者效力EJB啟動了新的事務，而該事務本該由一個已存在的EJB啟動為了平安，把數據分別級別定得太高處理方案:過度工程化的處理之道直接于極限編程(XP)方法：用最小的設計和編程來滿足需求，除此之外別無它干。除非他需求明確知道今后能夠的需求，如未來的負載要求，或者系統在最高負載下

11、的表現，否那么大可不用為系統未來的情況做太多思索或猜測。另外，J2EE平臺曾經定義了可伸縮性及出錯恢復等特性，可以讓效力器系統為他進展處置。在最小的系統中，只包含一個個小組件，這些組件只做一件事，只需把這些要求做到的進展實現，系統穩定性就曾經得到了提高，而且，他的系統的可維護性會變得很強，在未來要添加功能以滿足新的需求也將變得容易。備注:除了上面所列方案之外，可以推行設計方式-它們可以顯著地改良他的系統設計。EJB模型本身也廣泛運用了設計方式。例如，每個EJB所帶的Home接口就是Finder和Factory方式的實例。EJB的remote接口扮演了一種實踐bean實現的代理，并且對于提供容器

12、的才干也是至關重要的，這些容器截取調用信號并提供諸如透明transparent負載平衡的效力。忽視設計方式也是危險的一部分。我常提到要反對的另外一種危險是：僅僅是為了運用EJB而運用EJB。在他的運用中的某一部分能夠并不需求EJB，甚至他的整個運用都不需求。這是過度工程化所走的極端，而且我確實也目擊了一些良好的servlet和JavaBean運用被重構為EJB，而這樣做并沒有很好的技術上的理由。風險3:沒有將業務規那么和邏輯表現方式相分別工程階段：設計影響的工程階段：開發對系統的影響:維護、擴展性、性能病癥:過于龐大、沒有邊沿的JSP程序在業務邏輯改動的時候必需修正JSP在要求改動界面顯示的時

13、候需求修正并重新配置EJB和其它后臺組件躲避方案:J2EE平臺使他有時機將表示邏輯和導航控制相分別，進而與業務規那么相分別。這被稱為方式2構造。備注:可以使器具有一致性的設計來進展用戶界面框架的銜接。(例如可以運用taglib)，這將協助 他防止邏輯分別的問題。有許多現成的好的方法可供選擇。對每一個分別進展評價，然后采用最適宜的框架。風險4:沒有在開發環境中進展適當的配置工程階段：開發影響的工程階段:穩定化、并發、成熟期對系統的影響:他的權衡病癥:經過多日或數周的時間才干過渡到成熟系統風險存在與過渡期，帶有很多不確定性，有些主要的功能場景沒有被測試到實踐系統中的數據和開發、測試中的數據不同無法

14、在開發者機器上進展組建運用行為在開發、穩定化及產品環境中各不一樣躲避方案:處理之道是忠實地在開發環境中配置實踐的環境，讓開發所用環境接近于要實施產品的環境。假設未來環境是JDK1.2.2及Solaris7，那么不要在JDK1.3及RedHatLinux上進展開發。對于所用的運用效力器也是如此。同樣，要快速地看一下產品數據庫中的數據，并將這樣的數據用于測試。不要依賴于人工創建的數據。假設產品數據很敏感，那么要使之變得不敏感，然后把它配置起來。開發中未能預期到的產品數據將對以下過程產生破壞：數據檢驗規那么系統測試行為系統組件構建(特別地包括：EJB-EJB以及EJB-數據庫)最為糟糕的是，這樣還能

15、夠產生異常、空指針，以及他從沒見過的問題。備注:開發人員常把平安性問題放到穩定化階段才開場處理。要防止這樣的圈套產生，他也可以破費同樣多的時間在業務邏輯中改良平安性。成熟期是一個復雜的過程，其中充溢了技術性問題和非技術性問題。他能夠會陷于想不到的一大堆問題中，這就是成熟化所意味的一切。開發及穩定化環境過程為他提供了制造更多這樣的問題，以及發現這樣的問題的地方，不斷去做，就可以大大減少風險。他做的工程越多，他就越能了解什么是可行的，什么是不可行的。他可以對工程問題進展記錄，以防止同樣的錯誤反復發生。風險5:選擇了錯誤的提供商工程階段：提供商選擇影響階段：設計、開發、穩定化/負載測試，成熟化對系統

16、的影響:可伸縮性、性能、可維護性及穩定性病癥:開發人員要運用更多的時間來處置工具方面的問題，而不是很有效果地運用這些工具為了應付知的和未知的問題，而不得不進展顯著的系統重新設計在不同的工具之間很難進展集成運用效力器與IDE工具，IDE工具與調試器，源碼控制與合成工具，等等對于IDE工具和調試器等，開發人員往往排斥它們，而推崇本人所喜歡的工具躲避方案:為了防止風險5，他需求一個很好的提供商選擇過程，風險10的躲避也適用于此。要真正衡量一種IDE工具能否最適宜的方法是真正地進展運用。而獨一來評價一種J2EE運用的方法是建立一種概念實驗來進展證明，在實驗中要包含他的運用框架。現實上，他也不希望在破費

17、了3個月時間進展了培訓和開發后，在運用時又發現一些bug。假設在開發到一半的時候，忽然發現他的工具集有問題，那么他早應該知道，有些工具確實比另一些更重要。假設他所選的運用效力器不能充分滿足他的需求，他只好修正原先的設定。假設IDE不好，那么需求設置最低限制的代碼規范，并讓開發人員恣意選擇他們以為最為有效的工具。備注:要真正了解到哪一個供應商對一項特殊的義務來說最適宜，其實并不是一件一次性決議的事情。他需求不斷地跟蹤與評價這個市場。例如，在過去的一年里我用過4種不同的IDE工具，這取決于我運用了什么樣的運用效力器、平臺，能否運用EJB等。風險6:不了解他的提供商工程階段：提供商選擇影響階段:提供

18、商選擇階段后面的一切階段：設計、開發、穩定化/負載測試、成熟化對系統的影響:可維護性、可伸縮性、性能病癥:開發所用周期超越了最壞預測的周期1/3以上提供商曾經提供了某項功能，但開發者在不知道的情況下重新進展了該項功能的開發躲避方案:為了躲避這樣的風險，他可以盡能夠地訂閱提供商的網上資源，例如郵件列表、新聞組、版本信息尤其是其中的bug修復補丁的闡明等，他能從中得到無法估量之多的收獲。一旦他曾經選定了提供商，那么立刻就要投資進展培訓，并且盡能夠趕在工程啟動以前。然后，逐漸在團隊中建立起對此提供商的認識及信任。試著建立幾個EJB并部署一下，再用他的表示層技術(SwingGUI,JSP等)來調用它們

19、。假設他既要搭建開發環境，又要同時在實現工程目的，就會產生一些不用要的沖突。實踐上，我也見到過不斷沒有進展構建過程的情況：“我們沒有時間。因此，這些任務必需提早進展。有些人會說：“我們的方案中沒有為我們提供這些時間。我的回答是：“他的方案中并沒有不給他時間使他不這么做啊。備注:在J2EE世界里，各提供商產品的技術兼容性終究如何？讓我們看一下IBM和BEA的詳細分析吧。兩者都分別在各自的運用效力器中支持EJB1.1。那么，實踐上BEAWebLogic5.1和IBMWebSphere3.5終究有多少類似之處呢?BEAWebLogic和IBMWebSphere的系統配置和管理方式幾乎完全不同。IBM

20、在WebSphere中采用了全面的GUI環境，而與之相對的是，BEA在WebLogic中提供一整套命令行。IBMWebSphere運用IIOP來和CORBA異常進展通訊，這些異常對程序員來說是可見的；WebLogic根本沒有CORBA構造，而缺省運用t3協議。WebSphere和VisualAge銜接嚴密，而WebLogic是IDE無關的，實踐上，他幾乎可以運用任何的開發工具。由此可見，差別還是相當多。假設他是一種運用效力器的專家，并不意味著他就是一切運用效力器的專家。這種區別表達在IDE，debugger，build工具，配置管理等等方面。具備某提供商的某項特殊工具的運用閱歷，可以在評價該提

21、供商的競爭對手產品時具有一些便利。但是，不要奢望在不同產品之間進展無縫的轉移或銜接。因此，他不得不破費足夠多的時間在熟練掌握這些工具上。風險7:設計中沒有充分思索到可伸縮性和產品性能工程階段：設計受影響的工程階段:開發、負載測試及成熟化對系統的影響:可伸縮性、性能、可維護性病癥:無法忍受的速度緩慢系統給效力器端添加的繁重負擔，而無法利用到一些聚簇技術。躲避方案:把精神集中于性能和可伸縮性方面的需求，明確開發中要到達的性能目的。假設他需求每秒50個事務，而他的EJB設計只能提供40個，那么他就需求思索替代方案，諸如存儲過程，批處置，或者重新思索OLTP的設計。盡能夠讓他的提供商參與進來，他們應該

22、非常清楚其產品的強項和弱處在哪里，然后給他提供最直接的協助 。備注:本風險與風險2(over-engineering)似乎有些沖突。實踐上，兩者相互影響。我對風險2給出的處理方案是，只在絕對必要的情況下才進展構建。而對與性能和可伸縮性，他要預先劃分好什么是必需求做的。假設他實現就識別出系統需求非常強的可伸縮性，并把它作為一個比較關鍵的需求，那么他首先需求選擇一個帶有很強的簇支持及事務型緩存的運用效力器。另外，他應把業務對象設計為EJB，從而可以充分利用效力器架構的優勢。XP也沒有問題，他依然是只做絕對必要的任務。我把這樣的觀念看作是一種檢查和平衡的方法。我們只需求最簡單能夠性的系統，該系統只提

23、供客戶所需求的功能與行為即可。風險8:陳舊的開發過程工程階段：開發影響階段:穩定化，成熟化對系統的影響:可維護性、代碼質量病癥:工程方案看上去似乎類似于瀑布模型:“首先草構設計，然后在一個很長的周期里進展開發。由于不存在構建build過程，每次構建都象是噩夢構建的日期等于損失開發的日期，由于什么也沒有做成在集成以前組件沒有分別被充分地測試過，而集成測試意味著將2個不穩定的組件放在一同，然后查看堆棧里的跟蹤結果。躲避方案:好的軟件方法學將提高他的軟件生命期。此前我曾經提到XP方法，他可以在網上找到很多這方面的資料。備注:JUnit可以用來進展單元測試，Ant工具可以進展編譯與構建，這2種工具都對

24、XP方法有很好的支持。風險9:沒有好的架構方式工程階段：開發影響階段:開發、穩定化、成熟期對系統的影響：可維護性、可伸縮性、代碼質量病癥:在代碼中運用了很多次的中心庫中發現Bug。沒有建立日志規范-于是系統的輸出很難讀取或者解析。不良的不一致的異常處置。在有些站點中我們甚至可以看到，出錯信息直接暴露給了最終用戶，例如在用戶在他的購物車核帳時發送一條SQLException堆棧跟蹤信息，用戶接著會怎樣做？打給數據庫管理員要求對primarykey約束進展修補嗎？以下義務曾經被開發者以各種方式處置了無數次了，這些都有必要放在任何構架設計的第一批目的中。日志異常處置與資源的銜接(數據庫，名字效力等)構建JSP頁數據合法性檢查躲避方案:我是一個輕方法學的信徒和實際者。我在JavaWorld上的第一篇文章-FrameworksSavetheDa