論J2EE開發模式低效的原因：用戶無法參與開發
J2EE是一種利用Java 2平臺來簡化企業解決方案的開發、部署和管理相關的復雜問題的體系結構。J2EE技術的基礎就是核心Java平臺或Java 2平臺的標準版，J2EE不僅鞏固了標準版中的許多優點，例如"編寫一次、隨處運行"的特性、方便存取數據庫的JDBC API、CORBA技術以及能夠在Internet應用中保護數據的安全模式等等，同時還提供了對 EJB（Enterprise JavaBeans）、Java Servlets API、JSP（Java Server Pages）以及XML技術的全面支持。其最終目的就是成為一個能夠使企業開發者大幅縮短投放市場時間的體系結構。
J2EE體系結構提供中間層集成框架用來滿足無需太多費用而又需要高可用性、高可靠性以及可擴展性的應用的需求。通過提供統一的開發平臺，J2EE降低了開發多層應用的費用和復雜性，同時提供對現有應用程序集成強有力支持，完全支持Enterprise JavaBeans，有良好的向導支持打包和部署應用，添加目錄支持，增強了安全機制，提高了性能。
問題是:出于如此美好目的設計的技術,最后為何會變得如此低效,如此難以開發,難以維護呢?
原因當然是很多很多了.不同人有不同見解都是很正常的.要把所有原因分析討論完,怕是用盡所有的時間和硬盤也是不夠的.
在我看來,其中一個很重要的原因,就是在J2EE的整個開發維護過程中,在項目的整個生命周期里面,用戶的作用被忽視了,在整個J2EE的設計思路里面,根本沒有考慮過最終用戶將如何參與到整個系統的開發,設計,使用,以及后續的運維中來.
這才是J2EE整個理論體系的最致命缺陷.雖然目前隨著RIA應用的推廣,J2EE本身也在進行著演化,但到目前為止,整個理論體系仍然沒有突破這一限制.
J2EE本身的基本理論基礎,是以服務器為中心的設計思想,一切工作都在服務器上來完成和實現.客戶端是為服務器來服務的.在J2EE的整個理論體系里面,沒有考慮用戶界面應該如何優化,也沒有考慮用戶的實際體驗將是怎樣的.J2EE關注的重點和核心是后臺的服務器.
作為一個理論體系,J2EE是完整的,也是相當復雜,難以全部掌握的.
在實際項目中,用戶的參與是非常重要的,在項目的開發中,用戶不僅給出建議意見,在后續的維護中,更是用戶本身需要對系統的進一步發展演化來進行把關.
可以在J2EE的項目里面,用戶想參與到項目的整個開發過程中來,實在是太困難了.
用戶所能夠理解和發表意見的部分,在整個項目里面,是用戶的界面部分,操作的流程部分.這一部分,本身也是用戶日后使用中實際接觸的部分.
而按照J2EE的開發模式,絕大部分精力都花費在了中間層的J2EE技術上面,不同J2ee服務器之間的差異,各個開源框架之間的協調,各種技術bug的處理...所有這些把開發人員的時間和精力全部耗盡了,根本沒有余力來和用戶討論界面該如何組織,操作流程如何優化.
-------------------------------------------------------------
問題的另外一個方面,就是基于j2ee的開發模式下,界面的開發實在是太過困難了.
一旦你采用J2ee的技術架構,前臺的用戶界面,幾乎都選擇采用HTML語言來編寫,這樣的選擇也不難理解.J2ee剛出來的時候,當時只有HTML和Applet可以選用,當時javascript還沒有發展到今天的地步.一旦你的技術團隊選擇了java語言,其他方向的技術人員自然也就不在考慮范圍之內了.大家都用HTML來寫頁面了....
但問題是,HTML語言來編寫應用程序的界面,實在是太困難的一件事情.
-------------------------------------------------------------
如果只使用標準的HTML語言,不使用任何的樣式表的話,那么這個界面實在是太難看了.
而使用CSS的話,寫這樣的界面又增加了新的困難程度.
對了,現在還沒有說JavaScript呢,在頁面上增加javascript,在增加頁面功能的同時,也增加了頁面長度,這些增加的代碼,對于以后的系統維護,都是一顆顆地雷,后續者必須以百倍的熱情和謹慎,才能不被這些地雷炸傷.
-------------------------------------------------------------
上面的討論還是僅僅是在技術層次上進行的,其實還有更重要的一個方面沒有談到.
這就是界面開發上的所見即所得.由于Web界面開發的復雜性,沒有一個開發工具可以實現真正的所見即所得,只能在運行的時候才知道最終的結果到底是怎么樣的.
在這種情況下,除了增加開發的復雜度以外,用戶也就被排斥到了整個開發過程之外.
用戶沒有辦法對界面提出自己的要求,一是這種要求會被回應:對不起,做不到.對不起,難度太大.二是在整個界面的開發過程中,用戶本身是隔離其中的,用戶無法真正理解界面開發的全部過程,也就無法提出合適的意見出來.
-------------------------------------------------------------
這種將用戶隔絕在界面開發過程的惡果,就是用戶對最后的界面,包括觀感,包括操作流程,都不夠認可,于是經典的軟件工作模型開始了.
開發人員開發出版本1--->用戶提出修改意見1-->版本2--->意見2--->版本3--->意見3
整個循環在項目數次延遲以后勉強結束.
我們滿足用戶的需求了嗎?沒有.
為什么會有這么多次的反復呢?因為從一開始,開發者就沒有合適的途徑來接收用戶的反饋意見,只有把所有界面都完成才能開始接收用戶的界面反饋.因為沒有合適的機制,讓用戶來參與到整個項目的開發過程中來.
--------------------------------------------------------------
J2EE這個技術架構的致命缺陷,就是沒有考慮到用戶的參與,它關注于如何建立一個理想的技術烏托邦,而沒有考慮在現實的世界里面,沒有客戶的認可,整個技術框架都是空中樓閣.
--------------------------------------------------------------
任何的討論,都是有一個對立面存在的.
與J2EE相比,我選擇的參照物是Visual Basic(不是vb.net).
VB的最大優點,就是所見即所得,這個界面開發的過程,非常直觀,非常簡單,也非常容易理解.因此在VB的開發里面,用戶是完全能夠理解這個界面開發的全部過程,也能夠提出具體的修改意見出來的,甚至在培訓以后,由用戶自己來繪制一些界面和調整一些界面是完全可能的.
正是因為如此,采用VB這類工具開發的過程中,至少在界面這個層次上,修改是可控的,用戶對最終的界面是很容易認可的.
而在J2EE里面,事情就不是這樣了.
【編輯推薦】
