基於J2EE架構的公司專屬應用程式開發新思維：Web企業開發困境原因分析

從總體上來說，構成目前J2EE 企業開發效率低下的原因有這麼幾個：分工過細，技術路線多頭並進，客戶無法參與，開發的複雜度太高。這幾個方面的因素之間互為因果，相互作用，最後把整個開發過程拖入泥沼之中。下面詳細論述。

5.1分工過細

J2EE的整個理論體系，來自IBM這樣的商業化巨頭，因此他們提出的技術架構，整體上遵循的原則，就是強化分工，強化分層。把原本是屬於一個整體的應用系統，生生切分成使用者介面層，應用邏輯層，資料訪問層，資料存放區層多個不同層次，並且在每個不同層次上再進行不斷細化，將分工的特性發揮到了極致。這種分工方式在學術上也許是不錯的範例，但在實際的項目開發中，嚴格的分工就必然意味著多工種，多層次的人員溝通和協調。在實際工作中，工作究竟應該切分到那個層次來完成，是一個妥協的結果，而不是單純依賴學術探討可以得出結論的。

採用J2EE以後，無意中就會接受這種分工的工作模式和工作模型，並且預設按照這種模式來組建Team Dev，於是Team Dev就開始膨脹，有前台開發的，有後台開發的，再加上資料庫開發的，加上測試，專案經理光協調這麼多人的工作都快忙不過來了，又那裡有時間和精力來真正考慮一下項目的架構最佳化。

分工過細帶來的另一個負面效果，就是很多人一開始就只能局限在自己的一個工作崗位上，對其他人的工作缺乏真正的認知，項目群組成員裡面，除了專案經理以外，幾乎沒有機會真正掌握整個系統的整體概念，因此在思考問題的時候，無法超越本身角色的限制，只能就事論事。在整個項目角度來看，幾乎每個人都在盲人摸象，沒有整體概念，項目的很多問題都被掩蓋起來，到了最後關頭才集中爆發出來。

在軟體工程的觀點中，適度的資訊屏蔽可以減少無效資訊對工作人員的幹擾，以提高其工作效率和判斷能力；但當這種觀點走向極致，試圖把每個工作人員都當成只關心一點的機械裝置以後，整個項目組就變得極為機械，因為沒法掌握整體上的資訊，也無法真正從整體上對項目本身進行自省和改進。整個項目組很快就會陷入一種集體無意識之中。

5.2技術路線多頭並進

技術路線的問題和分工過細的問題有很強的聯絡。正因為分工被強化和強調了，不同崗位，不同角色的工作人員自然採用不同的技術路線來試圖解決問題，並逐漸發展出自己的一套技術路線出來。例如前端開發使用的是HTML語言，後來發展出CSS,JavaScript，而JavaScript又自己發展出若干套不同版本，適應不同瀏覽器環境的架構平台出來；而在後台開發的Java語言，先是發展出了JSP的標籤庫，又發展出JSTL，有了WebWork，又發展出Struts，又發展出Spring；和資料庫互動訪問的地方，有了Hibernate，又有了itabits等等之類；與此同時，又發展出log4j, 緩衝工具等多種東西出來。

之所以發展出這麼多新東西出來，原因之一就是強化分工以後，每個人都在試圖解決自己面臨的問題的時候，按照自己的思路提出了一個新東西，然後逐步發展，於是一個一個新東西就出現了。

這些新技術，新架構的出現，一方面確實簡化了某一部分的開發工作，另一方面，從整個項目開發的角度來看，使用的技術越多，項目本身也變得越來越混亂，開發和維護的隱性成本在不知不覺中在迅速增加。

Spring的出現就是這種情況的一個很好的註解，因為開發中使用的東西太多了，不好配置，於是Spring的發明人想了一個辦法，把所有這些東西打了個大包，裝在一起，起了個大名叫Spring。但坦率的講，這麼做真的可以簡化整個項目的開發嗎，我非常懷疑。

5.3開發維護複雜度太高

開發維護的複雜度問題，與分工過細，技術路線多頭並進又是互為因果的一個因素。當分工越來越細，越來越瑣碎，使用的技術越來越多，使用者只能大概有個瞭解的情況下，整個系統的開發複雜度增加了，需要懂很多技術知識的人組合起來才能完成一個項目；從維護的角度來看，維護的人員也必須懂得這麼多技術知識，才能保證系統的長期穩定運行。

開發的時候分工太細，使用的技術過多，最終必然導致開發和維護的複雜度增加，必然導致開發維護的成本居高不下。

然而不行的是，許多人面對這種問題的時候，本能的第一反應是繼續強化分工，試圖投入更多的人力來解決這一問題，卻忽略了分工過細本身就是這個問題的一部分，在試圖解決問題的同時反而強化了這一問題。

5.4客戶無法參與

由於J2EE整個開發模式的設計，沒有考慮客戶該如何參與，如何提出自己的意見。詳細的分析請見上面章節的分析。

同時，在一個如此複雜的開發環境中，開發人員自己都無法從整體上描述開發整體過程，開發的整體結構，在這種情況下，客戶本身更加無法介入開發的整個過程之中，而只能在程式開發完成以後再提出意見進行修改。

從使用者的需求到最終的程式實現，在一個複雜的開發流程中，需要消耗很長的時間才能完成，在此過程中，客戶是無法參與的。而對最終程式的修改意見，又將使項目的開發進入新的一輪變動之中，從而進一步拉長項目的周期。最後所有人都疲憊不堪。