避免這10項J2EE危機來確保JAVA項目成功

2019-11-18 12:26:19

字體：大中小

來源：轉載

供稿：網友

　　在我作為開發者、高級開發者、架構師的經歷中，我碰到過好的、差的甚至是丑陋的企業級java項目。當我問自己，是什么使一個項目成功而使另外的失敗，我發現很難得到一個完美的答案，就似乎很難用成功來定義所有的軟件項目。J2EE項目也不例外。因此，項目被分為不同級別的成功或失敗。在這篇文章里，我主要想為您??讀者朋友??揭示影響企業級JAVA項目的最大的10項危險。
　　
　　一些危險只是簡單的延遲項目進度，一些卻是錯誤的征兆，而還有一些使項目徹底沒有成功的希望。盡管如此，假如具有良好的預備，征程開始前相關的知識和熟悉地形的向導，所有的都可避免。
　　
　　這篇文章結構簡單，我會按以下方式來揭示各種危機：
　　
　　危機的名稱
　　
　　項目階段（PRoject phase）：危機所出現的項目階段
　　
　　所牽連的項目階段（Project phase(s) affected）：大多情況下，這些危機對隨后的“項目階段”有一種順帶（knock-on）的影響
　　
　　解決：避免危機的方式以及如何最小化它們的影響
　　
　　注釋：有關該危機我想透露的觀點，但不適合以前的分類
　　
　　如上所注，我們將在企業級JAVA項目背景和它的各個重要階段中檢查每一項危險。這些項目階段包括：
　　
　　供給商選擇：在你啟動J2EE工程之前，挑選你的最佳工具組合的過程??不論是應用服務器還是咖啡品牌
　　
　　設計：不論是嚴格的瀑布模型還是"code it and see"（試翻譯為：編碼和運行查看）方式，我對設計都有這樣一個觀點：我做了充分的設計，因此我可以輕松的進入開發階段。當我確切知道我在建造什么和如何建造時，我認為我的設計階段完成。另外，在進入開發階段之前，我使用設計模板來保證我對我自己問了所有正確的問題并且有了建議的解決方法。然而，我在該階段同樣也不害怕寫代碼；有時，這是回答問題的唯一方式，執行和模塊化（ performance or modularity）。
　　
　　開發：這個階段早期有大量工作要做。選擇好的工具加上一個良好的設計并不總是意味著開發階段會非常順利，但的確會很有用。
　　
　　穩定性/負荷測試：在這個階段，系統架構師和項目治理員將關注系統健壯性和構建質量，如確保系統的要害統計??并發用戶數，失敗的情境等。然而，直到這一階段，代碼質量和運行亦不應被忽略。事實上，你不能留一些差的或慢的代碼到健壯性階段來改。
　　
　　存在階段[live]：這并不是真正的項目階段，it's a date set in stone（想了半天也不知道怎么翻譯:-{）這是關于預備的階段，也是以前的錯誤的鬼怪出沒的地方，不論是差的設計、開發還是錯誤的（開發工具）賣主的選擇。
　　
　　圖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
　　
　　好，現在我將其分解成3個小主題來進一步闡釋。
　　
　　描述：不理解Java
　　
　　項目階段：開發階段
　　
　　所牽連的項目階段：設計，穩定階段，存在階段
　　
　　受影響的系統特性：可維護性，可測量性（scalability）,執行性
　　
　　征兆：
　　
　　重復實現已經包含于JDK核心APIs里的函數功能和類
　　
　　不知道下面所列的任何一項或幾項是什么和它們能做什么（下面列出了一些示例）
　　
　　垃圾回收（train, generational, incremental, synchronous, asynchronous）
　　
　　對象什么時候可以被“垃圾回收”??
　　
　　Java里面繼續特性的使用（及其權衡使用）
　　
　　方法重載
　　
　　為什么java.lang.String（此處替代你自己喜愛的類）似乎性能很差
　　
　　忽略Java引用的語義（與忽略EJB中值的語義相對）
　　
　　對非基本類型（nonprimitives）使用＝＝而不是實現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知識，尤其是了解它的優勢和弱點。Java的存在已經遠遠超除了一門語言本身，同樣重要的是理解這平臺（JDK and tools）.具體的，你應當具有做一名Java 程序員的資格（假如你還沒有的話）??你將對你有如此多不了解的東西感到吃驚。更進一步，將它作為你小組的一部分并向其他人推廣，這種方式同樣很有樂趣。更進一步，創建一份郵件列表，專心于Java技術并且保持下去。（我曾工作過的公司都有這些列表，大多數由于不更新而變的岌岌可危）向你的同伴學習??他們是你最好的資源。
　　
　　注：
　　
　　假如你或你團隊中的其他成員不理解這門編程語言和這平臺，你又怎么能期待建造一個成功的企業級Java應用呢？健壯的Java程序員對于EJB和J2EE假如鴨子對于水一般。與之相對，差的沒有經驗的程序員將建造一個質量差的J2EE應用。
　　
　　描述：不理解EJB
　　
　　項目階段：設計
　　
　　所牽涉項目階段：開發，穩定性階段
　　
　　受影響的系統特性：可維護性
　　
　　征兆：
　　
　　EJBs在第一次被調用后就不再管了（尤其是處于就緒池[ready pool]的無狀態session BEANS）
　　
　　非重用的（Nonreusable）EJBs
　　
　　相比于容器提供的，開發者不知道可依靠什么
　　
　　不符合規范的EJBs(fire threads,調用本地庫，試圖完成I/O操作等)
　　
　　解決：
　　
　　為提高你的EJB知識，花一個周末來閱讀EJB規范（1.1規范有314頁）。然后閱讀2.0規范（524頁）來了解為什么1.1規范不再適用和2.0規范能帶給你什么。關注規范中那些能告訴你??應用開發者??什么是在EJB中合法的行為的部分。18.1和18.2節是開始的好地方。
　　
　　注：
　　
　　不要從你的提供商（指應用服務器或其他開發軟件的提供商??譯者）的眼里看EJB世界。確保你了解符合規范的EJB模型和非凡的實現之間的不同。這將保證在需要時你可以將你的技術帶給你的提供商（或其他版本）。
　　
　　描述：不理解J2EE
　　
　　項目階段：設計
　　
　　所牽涉項目階段：開發
　　
　　受影響的系統特性：可維護性，可度量性（scalability），執行性
　　
　　征兆：
　　
　　“什么都是EJB”的設計
　　
　　手工配置而不是使用容器提供的機制
　　
　　客戶安全實現??J2EE平臺或許是在企業計算中最完全和完整的安全架構，從表現一直到后臺；它全部能力很少被全部使用的
　　
　　解決：
　　
　　學習J2EE要害組件以及每個組件所能帶來的優勢和劣勢。依次涉及各項服務，此處知識和能力一樣重要。
　　
　　注：
　　
　　只有知識能解決這些問題。好的Java 開發者造就好的EJB開發者??一步步地可以完美地成為J2EE領袖的人。你獲得越多的Java/J2EE知識，你在設計和實現方面的能力越強.Things will start to slot into place for you at design time.(想了半天也不知道怎么翻譯:-{ )
　　
　　危機2：過度設計（無論是否是對于EJB）
　　
　　項目階段：設計
　　
　　所涉及的項目階段：開發
　　
　　受影響的系統特性：可維護性，可測量性（scalability），可執行性
　　
　　征兆：
　　
　　特大型EJBs
　　
　　開發者無法解釋他們的EJBs做什么和它們之間的關系
　　
　　不可重用的EJBs,組件，或服務??當它們應該重用時
　　
　　當已經存在的事務可以完成任務時，EJBs 啟動新的事務
　　
　　數據獨立性被設定的太高（為了安全的目的）
　　
　　解決：
　　
　　解決過度設計的方法可以直接從XP（extreme programming）中找到：局部范圍內，設計和編碼實現最小的暴露的[bare minimum]部分來滿足需求，而不要做的過多。當你需要意識到將來的需求，比如平均負載需求和在系統負載頂峰時候的行為，不要試圖“第二次猜測”[second-guess]系統將來需要成為的樣子。另外，J2EE平臺為你定義了特性如可測度性和服務器底層需要捕捉的任務錯誤。
　　
　　注：
　　
　　除了上面的解決方式，使用設計模式??它們會顯著的提高你的系統設計。EJB模型本身廣泛地使用設計模式。如，每個EJB里的Home接口是一個尋找者和工廠模式的例子[Finder and Factory pattern].一個EJB的遠程接口擔當實際bean的實現的代理，也是容器截取調用和提供服務如透明化負載均衡的能力要害。忽略設計模式的價值是危險的。
　　
　　我不斷強調的另一種危險是：為使用EJB而使用。你的應用的一些部分在不適合被當作EJB模型時候而被設計為EJB模型，你的整個應用似乎使用EJBs將獲得無限價值。這是極度的過分設計，我曾看到完美的servlet 和 JavaBean 應用在并沒有好的技術方面的原因而使用EJBs時，變的亂七八糟，不得不重新設計。
　　
　　危機3：未分離表示邏輯和商業邏輯
　　
　　項目階段：設計
　　
　　所涉及的項目階段：開發
　　
　　所影響的系統性能：可維護性，可擴展性，可執行性
　　
　　癥狀：
　　
　　大型且笨拙的jsps

上一篇：介紹關于IBM MQSeries的使用指南

下一篇：回眸Java10周年：J2EE從起源到目的一