淺談J2EE開發 之 穩定的代價

一如既往，本文不涉及過多的J2EE開發的技術細節，如果想關注這方面內容，請參閱其他書籍。本文也不適合J2EE開發的新手作為入門教材閱讀，謝謝配合。本文的主要目的是整體的介紹一下J2EE開發在我眼中的現狀，以及個人對未來趨勢的一些看法。

首先，先談談EE這兩個字母。所謂的EE，就是Enterprise Edition，企業版。顧名思義，這個東西是針對企業開發來制定的。那麼討論一下，企業開發需要什麼東西？

第一，肯定是壓倒一切的穩定。作為企業來說，商務才是第一位的東西。技術什麼的，在商務面前都是要讓步的。你技術再先進，良品率不高也不行。或者你技術獨步宇內，但是隻有你一個人能做，那也是不行的。而商務需要的東西，從技術層面來說，是穩定和高效。也就是說，你首先得穩定，最好是MTBF非常高。其次是高效，最好是幾KB記憶體能搞起一個網站來。

第二，是易用。也就是說，最好你能自己猜測使用者心意。使用者咳嗽一下，你就知道使用者要填啥；使用者皺皺眉頭，你就知道使用者想點哪個按鈕。

那麼，在實際開發中，除了這兩點以外，還有什麼是企業級應用中比較關心的呢？就是兩個字，支援。這裡的支援除開對Bug的及時修復以外，還有就是對客戶其他方面的一些支援。比如業務有改變了，你的修補速度等等。

現在來談談穩定。高效，易用這幾個主題會分別在接下來的三篇裡提及。為避免一篇內容過多，所以分成四篇來寫。

談穩定之前，先來看幾個概念。

第一個是魯棒性，英語原文的Robust。所謂魯棒性就是系統的健壯性，它是在異常和危險情況下系統生存的關鍵。比如說，計算機軟體在輸入錯誤、磁碟故障、網路過載或有意攻擊情況下，能否不當機、不崩潰，就是該軟體的魯棒性。所謂“魯棒性”，是指控制系統在一定（結構，大小）的引數攝動下，維持某些效能的特性。根據對效能的不同定義，可分為穩定魯棒性和效能魯棒性。以閉環系統的魯棒性作為目標設計得到的固定控制器稱為魯棒控制器(以上內容來自百度百科)。

而穩定在J2EE系統來說，表現在一個一個的框架的堆疊，每個部件的穩定，造就一個系統的穩定。而一個一個的框架的穩定，來源於廣大使用者的測試。

J2EE世界很崇尚自由的風格，所以也造就了很多免費的框架，其中最典型的就是Rod Johnson開發的以一己之力挑戰EJB的Spring。現在Spring的主版本號已經到3了。Spring 1我沒用過，不置可否。2和2.5我用過，開始尚且可以習慣，所有的核心類都在一個jar檔案內，配置框架的時候有MyEclipse的協助，還行，不算很難。只不過呢，有的時候用到一些比較少見的類的時候，就比較受罪了。因為分佈於很多jar中，不知道到底是哪個jar，又不能一起甩進去，也不能一個一個試驗，沒時間，沒精力。比如我寫tag的時候，本來是繼承TagSupport的，如果要從Spring Context中獲取到request的話，要繼承一個叫RequestContextAwareTag的類，來自於org.springframework.web.servlet.tags.RequestContextAwareTag。雖然這些都可以查到，但是說實話，以一己之力，想了解全貌，實在太難了。

更讓我吃不消的，是Spring3的釋出。Spring3將原先的幾個主要的jar全部拆散，我第一次用到的時候，看到了滿眼的資料夾以及滿眼的jar檔案，當時第一反應就是兩眼發直，傻掉了。因為又缺少必要的本地化文件支援，又缺少時間來研究到底哪些jar是必須的，最後只好作罷，放棄使用這個框架。而如果回頭使用2.5的話，又有些不甘心。因為玩的基本上比較熟了，想挑戰一下自己。況且，能引起主版本號變化，肯定是有很多的改變的。最後在兩難的抉擇下，只好放棄了Spring。而一旦放棄Spring，基本上就意味著放棄了其他主要框架，比如Struts2。最後實在是沒辦法了，只有拿出原先搭配好是Spring2.5+Struts2的一套程式碼，完成了這個專案。

其他的框架就不再表過了，比如Struts1的為人詬病的難以解耦，Hibernate的效能問題，這些都是無法面對又不得不面對的問題。

不可否認，除開上面這些問題，SSH這三個框架是十分經典的。每個框架都很經典，對開發模式的理解和其他功底都很深刻，只是，我實在是有話要說。

優秀加上優秀並不等於另一個優秀，很有可能是無法接受的結果。

比如說，SSH框架，從入手到熟悉到能除錯各種千奇百怪的Bug，至少需要一年時間，而且是外包的工作方式，也就是純粹的碼農，在無盡的實戰中加深理解，遇見各種問題。而且，從另一個層面來講，三個框架的風格並不一致。比如說，Spring因為自身功能複雜，導致了xml檔案的編寫方式非常複雜；Struts2因為來自WebWork和Struts1的關係，配置檔案是一脈相承的。Hibernate的話，基本是個OOP性質的配置檔案。三個風格各異的配置檔案，湊在了一起，那麼。。。反正我是沒招架住，放棄了。所以我到現在還是不會用SSH，呵呵。好在我求職的話，已經不需要再拿SSH說事了，算是僥倖。

所以說，J2EE的穩定是有代價的，就是開發人員的操勞和不斷的學習。而這種學習，又不是能輕易解決的，需要長時間的，堅持不懈的學習。最無奈的是，這種學習是一過性的，也就是說，你學習的知識一旦被主流開發拋棄，那您就只好從頭再學一遍啦。

所以呢，我一直髮現一個比較有意思的現象。在每期程式設計師的開頭，都有一些文章是各種技術前沿的文章。所有的微軟系的技術專家都是紅光滿面的，而Java系的技術專家都是很勞累的樣子。學的太多了，能不累麼。學完SSH了，如果公司要用什麼新框架，還得學。再過一陣公司說要用EJB了，還得學。而且學過EJB2再學EJB3,基本等於重新開始。

發完牢騷，我最後想提出一個問題。J2EE的這些框架，真的穩定麼？不盡然吧。都是社群的傑作，常規使用當然沒問題，但是高密度的商業應用呢？比如我們一天24億條資料，資料量達到每天80GB的應用，我還真不敢拍胸脯。

要下班了，晚上有人請客吃肯德基，呵呵。明天來談J2EE的高效。