J2EE項目風險
一、概述
當您開始著手一個企業級JAVA項目的時候，您必須對很多方面進行權衡：供應商關系，為保證完整性在設計和開發階段的過度設計。每個都會帶來與生俱來的的一些風險，其中一些是非常明顯的，而其他則不怎么明顯。但是所有這些風險都是可以避免的。在Humphrey Sheil的這篇文章中，他分析了有可能對企業級JAVA項目的成功造成威脅的10個風險，并且描述了避免方法。
在我當程序員、高級程序員和系統構架師的各個時期，我見證了許多企業級JAVA項目的喜怒哀樂！當我思考到底是什么導致項目失敗或者成功的原因的時候，我發現很難找到一個完美的答案，因為為所有的軟件項目定義什么是成功是很難的。J2EE項目也不例外。而且，項目的成敗不是絕對的。在這篇文章中，我將展示影響企業級Java項目成敗的前10個風險，并將他們展示給您。
一些風險會延遲項目的速度，一些則是錯誤的岔路，另外一些則會使項目完全失敗！但是，只要有好的準備、有關的知識儲備以及對其有一定了解的知道者，這都是可以避免的。
這篇文章的結構很簡單；我將對每個風險按照下面的格式講述：
風險名稱：描述風險的一行文字。
項目階段：風險發生的項目階段。
受影響的項目階段：在很多情況下，風險是影響項目的后邊階段的。
征兆：風險的相關征兆。
方案：如何避免這種風險以及將其對項目的影響降低到最小。
備注：我沒有在前邊條目中提到的但是必須要提醒的關于風險的一些東西。
我們將在企業級Java項目的重要的階段檢查每個風險。項目涉及到的階段有：
選擇服務提供商：在開始J2EE項目之前選擇最好的工具組合－從應用服務器到什么品牌的咖啡。
設計：嚴格的瀑布方法學模型和“編碼然后運行”方法都依賴于設計：我進行足夠的設計然后就可以開始開發了。我對設計階段進行全面思考以保證在開始開發之前我已經思考了所有的問題和解決方案。但是、我并不害怕在這個階段編碼，有時這是回答有關性能和模塊性問題的唯一途徑。
開發：在這個階段我們前期階段的工作的效果將會顯現出來。好的工具加上好的設計并不意味著開發階段會很順利，但是確實有幫助！
穩定性負載測試：在這個階段，系統構架師和項目經理要將系統特性凍結，開始關注于構建質量，并保證系統的重要參數指標滿足要求－并發用戶數，失敗次數等。但是，質量和性能不能在前邊的階段被忽略。您不可能寫低質量或運行速度緩慢的代碼留到以后再去修正。
維護：這其實并不是工程的一個階段，它只是一個時間段。這個階段都涉及到了準備階段。前期的錯誤（糟糕的設計以及開發階段對供應商的錯誤選擇）將會顯現出對你項目構成威脅。
圖一顯示了項目各個階段的不同的風險（特別是對后期造成的風險）
好了，先不管別的亂七八糟的東西了，咱們開始看一看10個最大的風險吧！
二 風險分析
（一）風險1：不懂Java、EJB或者J2EE。
我將逐條分析前面所說的三個東西。
描述：不懂Java。
工程階段：開發。
受影響階段：設計，穩定階段，維護階段。
受影響的系統特性：可維護性、可量測性以及性能。
現象：寫JDK核心API已經有的函數和類。
不知道下面所列的這些東西（下邊列出的只是一些例子而已）：垃圾收集；什么時候實例會被垃圾收集――懸掛引用問題；Java中的繼承機制（或者他們的折衷選擇）；方法覆蓋和重載；為什么 java.lang.String（這里它替代了你喜歡用的類）會導致糟糕的性能；Java的引用傳遞（與EJB中的傳值相比較）；使用＝＝與實現equals() 方法這種非初級應用相比較；Java在不同平臺上的不同的線程調度策略（例如空閑還是非空閑）；綠色線程與本地線程的比較；熱點（為什么舊有的性能調節技術否定熱點優化）；JIT以及什么時候好用的JIT變得不好用（例如不安裝JAVA_COMPILER的時候您的代碼仍然完好的運行等等）；Collections API
RMI（遠程方法調用）
解決方案：
您必須加深java的相關知識，特別是關于它的強項和弱項。Java已經超越了語言的范疇。理解它相當于理解一個平臺（JDK和相關工具）。具體來說，如果您還沒有取得Java程序員認證您必須去取得－您會驚訝的發現您還這么多不了解的。如果把這做為你項目組并且將它推行到每一個人就更好了，而且也更有趣。如果有可能的話家里一個郵件列表來討論Java技術并且保證它的活躍那就更好了。（我工作國的每個公司都有這樣的郵件列表，但是他們大部分由于沒有足夠的人氣而奄奄一息）。向你的開發同事學習――這就是最好的來源。
備注：
如果您或者您的開發團隊成員不懂這門語言以及這個平臺的話，您能希望您的團隊能開發出成功的企業級Java程序嗎？高級的Java程序員使用EJB和J2EE將會非常容易。相反，低級的或者是經驗不足的程序員則會將J2EE系統弄得質量很差。
描述：不懂EJB
項目階段：設計
項目影響階段：開發、運行
影響到的系統特性：可維護性
現象：EJB只被使用一次（特別是返回到等待池衷的無狀態會話Bean）
不可重用的EJB
不知道程序員要做什么，容器能提供什么。
不符合規范的EJB（使用線程，調用本地方法，嘗試訪問IO等等）。
解決方案：
Description: Not understanding J2EE
為了增加您對EJB的知識，請拿出一個周末的時間看一下EJB規范（1.1版有314頁）。然后閱讀2.0規范以了解1.1規范沒提供了什么而2.0提供了什么。特別要注意告訴做為應用程序開發者的您在EJB中怎樣做才是規范的做法的那些章節。
備注：
不要從供應商的角度看EJB世界。你一定要了解EJB規范和特定容器的EJB實現之間的差別。這將有利于您在必要的時候將開發經驗用到其他供應商（或其他版本）上去。
項目階段：設計
項目影響階段：開發
受到影響的系統階段：可維護性，可擴展性，性能
現象：
一切都是EJB的設計。
使用手動事務管理而不是使用容器提供的機制。
定制安全機制――J2EE平臺提供了盡可能完善的集成化的安全構架，從頭到尾我們很少用到它的全部功能。
解決方案：
學習J2EE的關鍵部件以及它們優缺點，并把它們列成表格形式。弄清楚它們的每項服務，記住“知識就是力量”。
備注：
只有知識才能修補這些錯誤。一個好的Java程序員將會是一個好的EJB開發者。您掌握的J2EE和Java的知識越多，您在設計和實現階段做的就會更好。這些將會在設計階段開始顯示作用。
風險2：過度設計（使用EJB還是不使用）
項目階段：設計
受影響項目階段：開發
受影響系統特性維護、擴展性，性能
征兆：
過大的EJB
開發者無法解釋他們的EJB在做什么以及他們之間的關系。
不可重用的EJB、組件或者服務
本應該使用已有事務的時候EJB啟動了一個新的事務
為了安全，把數據獨立級別設太高
解決方案：
對過度設計的解決方案直接來自于極限編程（XP）方法學。用最小的設計和編程來滿足需求，除此之外其他的不考慮。除非你需要明確知道今后可能的需求，如將來的負載要求，或者系統在最高負載下的表現，否則大可不必為系統將來的情況做太多考慮或猜測。另外，J2EE平臺已經定義了可伸縮性及出錯恢復等特性，可以讓服務器系統為你進行處理。
在最小的系統中，系統由一個個小的組件組成，每個組件完成一個單獨的工作。這樣系統的可重用性得到改善，系統的穩定性也同樣得到改善。而且，系統的可維護性得到增強，并且未來新的需求的加入也將變得更簡單。
備注：
除了采用上邊的解決方案，也可以采用設計模式。它們可以顯著改善您系統的設計。EJB模型本身也廣泛的使用了設計模式。例如，每個EJB的Home接口都是Finder和Factory模式的例子。遠程接口則是真實Bean的代理，對于提供容器的能力也是至關重要的，這些容器截取調用信號并提供諸如透明負載均衡的服務。忽略設計模式的價值將會讓是非常危險的。
另外一個我常常警告的風險就是為了EJB而使用EJB。在你的應用中的某一部分可能并不需要EJB，甚至你的整個應用都不需要。這是過度設計所走的極端，而且我確實也目睹了一些良好的servlet和JavaBean應用被重構為EJB，而這樣做并沒有很好的技術上的理由。
風險3：沒有將業務規則和邏輯表現形式相分離
項目階段：設計
受影響項目階段：開發
受影響系統特性維護、擴展性，性能
征兆：
過大的沒有邊界的Jsp
您發現您在業務邏輯發生變化的時候在編輯JSP頁面。
顯示上的改變迫使你修改并重新部署EJB和其他后臺組件
解決方案：
J2EE平臺使你有機會將表示邏輯和導航控制相分離，進而與業務規則相分離。這叫做Model 2框架。如果您已經陷入這個陷阱，您可以使用重構。
備注：
可以使用具有一致性的設計來進行用戶界面框架的連接（例如taglibs）浙江有助于您在您的項目中將業務規則和邏輯表現形式相分離，不需要您創建一個新的GUI框架，現在已經有很多穩定的實現。對他們一次進行評估，然后選出一個最符合您需要的框架來。
風險4: 沒有在開發環境中進行適當的配置
項目階段：開發
受影響的項目階段: 運行、并發、成熟期
受印象的系統特征:你的權衡
征兆：
經過多日或數周的時間才能過渡到成熟系統
風險存在與過渡期，帶有很多不確定性，有些主要的功能場景沒有被測試到
實際系統中的數據和開發、測試中的數據不同
無法在開發者機器上進行組建
應用行為在開發、穩定化及產品環境中各不相同
解決方案：
風險4的解決方案是忠實地在開發環境中配置實際的環境，讓開發所用環境接近于要實施產品的環境。如果客戶的運行環境是JDK 1.2.2和Solaris 7，那么不要使用JDK 1.3 和Red Hat Linux進行開發。而且不要在一個應用服務器開發而在另一種應用服務器中運行。使用實際產品的數據進行測試，而不要依靠于手工錄入的模擬數據。如果產品數據很敏感，則要使之變得不敏感，然后把它配置起來。開發中未能預期到的產品數據將對以下過程產生破壞：
數據校驗規則
系統測試行為
系統組件構建(特別地包括：EJB-EJB以及EJB-數據庫)
最為糟糕的是，這樣還可能產生異常、空指針，以及你從沒見過的問題。
備注：
開發者常常將安全問題留到穩定階段才解決（程序界面很好的運行，我們現在加上用戶校驗的東西吧）。要防止這樣的陷阱產生，你也可以花費同樣多的時間在業務邏輯中改進安全性。
成熟期是一個復雜的過程，其中充滿了各種非技術的和技術的問題。你可能會陷于想不到的一大堆問題中，這就是成熟化所意味的一切。開發及穩定化環境過程為你提供了制造更多這樣的問題，以及發現這樣的問題的地方，不斷去做，就可以大大減少風險。
你做的工程越多，你就越能了解什么是可行的，什么是不可行的。你可以對工程問題進行記錄，以避免同樣的錯誤重復發生。
風險5：選擇錯誤的供應商
項目階段：供應商選擇
受影響項目階段：設計，開發，維護，測試，運行
受影響系統特性：性能，可維護性，穩定性。
征兆：
開發者花費大量時間跟開發工具腳勁而不是使用他們進行高效率的開發。為了解決已知的或未知的Bug，系統需要重構，并且不同的開發工具幾乎無法整合（應用服務器和IDE，IDE和調試器，源碼控制和構架工具等等）
對于IDE，調試器等，開發者會贊同使用他們喜歡的工具。
解決方案：
為了避免風險5，您需要一個好的供應商選擇流程，風險10也適用于此。
對于IDE，唯一的評估它的途徑就是使用它。評估J2EE實現的唯一途徑就是構建一個試驗并對您關心的系統的特性進行試驗。您肯定不希望您花費了3個月時間開發并進行了培訓后才發現系統有很多的bug。
如果在開發過程中，您對您的工具集有疑問怎么辦呢？當然一些工具肯定會比另一些表現好。如果你現則了不滿足您要求的應用服務器，那么請吸收它然后修改開發規范。如果IDE不好用，請降低代碼標準（使用制表符還是空格）。讓開發者選擇使他們更高效的開發工具。
備注：
要知道最好的供應商和工具不是對一個特殊任務的一次性工作。您要經常進行市場評估。例如，我在過去的12個月中使用了四個不同的IDE，這依賴于我的應用服務器、平臺還有是否編寫EJB。
風險6：不了解供應商
項目階段：供應商選擇
受影響項目階段：供應商選擇之后的所有階段－設計，開發，維護，測試，運行
受影響系統特性：可維護性，可擴展性，性能
征兆：
開發時間比預想的長了超過33％，開發者重新發明輪子――開發供應商已經提供的需求的特性。
解決方案：
為了避免不了解供應商造成的風險，訂閱所有供應商提供的資源，您可以在郵件列表、新聞組和版本備注（特別是已修正的bug列表）中得到您評估需要的信息。
一旦確定了供應商，請盡快開始培訓，在項目開始前越早越好。下一步，構建一個快速模型來證明，從而打消開發團隊的顧慮。構建EJB并部署它們，然后在表達層（Swing GUI, JSP等等）中調用他們。如果您在進行系統開發的時候才進行開發環境的搭建，那么環境搭建常常會造成麻煩。我看到過這樣的項目，他們沒有一個構建流程，“我們沒有時間了”。當團隊必須工作到11點的時候表現的更為明顯，每晚他們只是將程序拼起來然后運行。磨刀不誤砍柴工－這樣做會節省你很多時間。有人會說“我們計劃中中沒有安排這個時間”，我說“您的計劃中沒有不去這么做的時間”
備注：
不同的供應商對J2EE的特定的實現技術是不同的。讓我們看看一個兩個供應商的例子：IBM和BEA。IBM采用圖形化的WebSphere環境，恰恰相反，BEA則為WebLogic提供很多的命令行工具。IBM的WebSphere使用IIOP進行通訊，并拋出CORBA異常（對程序員非透明），WebLogic則沒有采用CORBA底層構架而是默認使用t3協議。
WebSphere與Visual Age是緊密結合在一起的，而Weblogic則是可以使用多種IDE的。您可以使用幾乎任何IDE進行WebLogic的開發。
他們之間是還是有不同點的。你是一種應用服務器的專家并不意味著你是其他應用服務器的專家。上述各點體現在各個方面：IDE、調試器、構建工具，配置管理等等。在一個特定工具上熟悉的人可以在評估該提供商的競爭對手產品時具有一些便利。但是這并不意味著您可以把程序在不同程序之間進行無縫鏈接。因此，您必須花費一些時間來熟悉這些工具。
風險7：沒有考慮可擴展性和性能
項目階段：設計
受影響項目階段：可擴展性，性能，可維護性
征兆：無法接受的慢速的系統（不應該服從重構）
服務器端被很強的負載所壓迫，導致不能充分發揮集群技術的全部優勢。
解決方案：
在這個風險中，我們接近我們系統性能的可擴展性需求－我們在您開始開發之前要知道您需要什么參數。如果您需要每秒50個并發事務數，而您的實體Bean只能提供40個，那么您需要尋找其他可選的解決方案，例如存儲過程、批處理或者重寫聯機事務處理系統。
您要讓供應商參與到系統性能需求中去――他們知道他們產品的強項和弱項，這樣可以對您有相應的幫助。
備注：
沒有為可擴展性和性能進行設計看起來與第二個風險（過度設計）相沖突。實際上他們是互為補充的。對于風險2我提倡只實現真正需要的功能。通過說明性能和可測試性要求，您可以設定需求的上界。
如果您認為可擴展性是一個重點要求的話，您就需要首先選用一個帶集群支持的應用服務器，可能還需要一個事務緩沖池支持。您還需要象EJB這樣的業務組件引擎，因為您可以充分利用服務器的系統構架。在這一點上極限編程將不會有任何問題，在極限編程中系統是用來滿足客戶的功能和行為要求的。
風險8：缺乏開發過程控制。
項目階段：開發
受影響階段：維護，運行
受影響系統特征：可維護性，代碼質量。
現象：
項目計劃看起來象瀑布模型：首先根據草案設計系統，然后我們就坐下來開始漫長的編碼。因為構建過程不存在，所以構建成了一個夢魘。構建的日子也就是停止開發的日子，因為我們什么都沒得到。
組件在集成之前沒有經過足夠的測試。集成測試意味著將兩個不穩定的組件捆在一起，然后到調試器的堆棧樹中去觀察他們。
解決方案：
一個好的軟件方法學將會節省您的生命。我已經提過了XP；在參考資料章節中我給出了相關的站點。在那里您會對XP有更深入細致的了解。
備注：
我無法想象我不使用Junit進行單元測試和Ant進行構建的日子（這兩個免費工具支撐著XP方法學）。如果想了解更多關于Junit和Ant，請參考資源這一章。
風險9：使用框架失敗
項目階段：開發
受影響項目階段：開發、維護、運行
受影響系統特征：維護性，可擴展性，代碼質量
征兆：
核心類庫中的Bug在代碼中多次使用
沒有設定日志標準，所以輸出不能此采用腳本進行讀取和分析
錯誤的或不協調的異常處理。我再有的站點看到，終端用戶可以看到系統的低級錯誤；例如當用戶要將他們購物車中的商品付費的時候出現一個SQLException 的stack trace。用戶應該怎么辦呢？難道要求他給數據庫管理員打電話，然后要求他修改主鍵約束錯誤？
下面的任務必須以某種方法進行處理，并且要成為任何構架的第一目標：
日志：
異常處理
奪得到某些資源的連接（例如數據庫、命名服務）
構建Jsp 頁面
數據校驗
解決方案：
我對輕量級框架非常情有獨衷，實際上，我在JavaWorld上的第一篇文章就是《框架節省時間》，它討論的就是企業及Java環境衷的框架。如果您已經在開發了，那么通過使用一個框架您仍然能夠收獲頗豐。在重做這些東西的時候，您將會遇到諸如錯誤處理和日志之類的錯誤，但是從長遠來看這會大大節省時間和金錢。
備注：
當在選擇框架和基礎組件開發的時候，您必須思考他們的不同的重用級別。第一級別的重用率時0.9甚至更高，也就是說項目中90％將會用到它。
風險10：項目計劃和設計建立在市場炒作上，而非實際的技術上。
備注：一開始我沒有把風險10加上來，后來我發現很多人都對企業級Java有誤解，特別是對于剛剛解除這個領域的人。
項目階段：所有受影響的階段，特別是供應商選擇階段尤甚。
受影響項目階段：所有階段。
受影響系統特性：可維護性，可擴展性，設計質量，編碼質量。
征兆：
因為EJB是可移植的所以在技術選型方面不重視。
在供應商選擇時沒有進行產品試驗
在項目生命周期衷需要更換開發工具。
解決方案：
別輕信項目外任何有即得利益人得說法。也就是說：不要輕信供應商（除非您對他們非常了解），不要輕信白皮書（因為他們是供應商花錢買的）。如果您需要真正得建議，那么請查找關于它得相關評論。甚至，可以下載您想評估得工具，在上邊試著開發一個小的系統原型。不要運行工具中自帶的例子（每個好一點的供應商都會加上這個）。
為了概括總結，花一定的時間為您的項目選擇正確的供應商和工具集。縮小您的選擇范圍到三四個供應商，然后進行測試。對您選擇的IDE、應用服務器進行為時一周的測試和構建。熟悉您將要用來開發項目的工具。
三 總結
只有這10個風險需要注意嗎？
10只是一個武斷的與其他風險分割開的數字而已，還有很多其他的風險。我就能說出很多。但是即使如此，如果您能說出我這列出的這些風險，我就可以保證您的項目會非常優秀而且必定成功。
如果還有我不想讓您獨這篇文章的原因就是：這不是經驗和計劃的代替品。如果您沒有經驗，那么請去積累。不要依賴項目開發中的培訓會起多大的兆月年個。在開發前請做好心理準備。請Java和J2EE指導者對你們團隊進行全程指導、把握項目方向，并和較少經驗的團隊人員一起成長。
最后，我寫的越多我想到需要說的東西越多：
軟件工程的社會因素
單元測試與集成測試（什么時候進行測試？）
設計模式
異常處理
唉，不能再寫了。等待著新文章吧，祝君好運！
結論：
這里列出了10個風險，他們能夠概括您進行企業級java開發的時候遇到的大部分問題。我堅信，您在開發過程中，還會面對很多其他的缺陷，但是我也堅信我已經概括了主要的問題。我們翻個個，將10個風險按著優先級排序：
不懂Java,不懂EJB,不懂J2EE
過度設計（使用EJB還是不使用）（設計模式）
沒有將業務規則和邏輯表現形式相分離
開發時沒有部署
選擇了錯誤的供應商
不了解您的供應商
沒有設計可擴展性和系統性能
陳舊的開發過程
沒有使用框架
項目計劃和設計建立在市場炒作上，而非實際的技術上。
原文：
http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-ten.html
英文水平有限，請多指教