耐心無止境成功一瞬間

BlogJava 聯系聚合

管理

31 Posts :: 5 Stories :: 25 Comments :: 0 Trackbacks

常用鏈接

留言簿(3)

隨筆分類(30)

隨筆檔案(31)

文章分類(1)

Java(1)

文章檔案(5)

My links

搜索

閱讀排行榜

評論排行榜

值得思考的問題

在jdon上看了一個帖子，感受頗深，有一種“一語驚醒夢中人”的感覺。

我們為什么選擇spring（或者其他框架），為什么出現了IOC,AOP,ORM等等？簡單回答是“解決問題”，但他們解決不同的問題。

需要繼續思考一下，希望能有所“突破”

參考url：http://www.jdon.com/jivejdon/thread/35373.html

防止斷鏈，轉載如下：

轉載內容
一晃眼搞了7、8年的企業應用管理和研究，各種技術、思想翻來覆去折騰了很久，最近總算是有點持撥云見目的感覺了，于是放出點大標題和各位論論道。

主要觀點其實在一年半前，已經在jdon首發的文章“堅持發揚EJB、Spring的光輝思想，將組件化進行到底！”(可參 http://www.jdon.com/jivejdon/thread/31834.html)進行過論述。當時雖然觀點比較激烈，然實際上筆者領悟得不夠深刻，故有后面一年多的RoR和PHP之實踐。隨著時間的推移，與各相關方(上級領導、企業領導、用戶、開發商主管、設計人員、開發人員、維護人員等等)的更多觀點接觸，讓我逐漸深入領悟了Java和Spring所蘊含的開發哲學和思想，于是又有此文。
(上文剛剛收到blog，由于是老文，不再發布了，僅作為整理收錄)

如果說，每種編程語言和技術都有自己的目標和歸宿和話，那么簡單來說，JavaEE和后來的Spring是為企業應用而生的。他們誕生的基本目標，正是為了解決困擾企業應用多年的各種復雜問題。故而他們能夠達到現在的領導地位，并將一直延續下去。

世間各種事業，都應該是“統一規劃，分步實施”。放到信息工程來說，就是“自頂向下設計，自底向上實現”。道理誰都明白，可現實當中執行下來，總是要走樣。問題就在于，這二者該如何結合？于是實際項目中，企業用戶、分析師、設計師、程序員、維護人員總是不歡而散，最后往往各行其事，一盤散亂。上層的總是抱怨下層在“亂搞”，而下層則嘲笑上層只會“空談”。結果往往是早已扔進檔案袋的系統方案和圖表，一堆各種公司、各種程序的“系統”，蒙頭蒙腦瞎忙的維護人員。

那為什么結合不了？因為大家沒有“共同語言”。開初UML跳出來了，分析師講得頭頭是道，程序員看得心煩意亂，用戶更是云山霧水。于是連MF都有點煩了，干脆推起了RoR。這乍東西一看太理想了。幾乎是分析員可以直接實現程序，而程序員也可以直接分析了。可惜世間難有完美的事物，RoR這種過于“ 霸道”的東西也許還是有問題的。前有foxpro，后有VB、PB，也許是筆者總是心有余悸，對這種過于“完美”的東西還是先放一放吧。

那是不是說，大家真的不可能有“共同語言”？筆者以為，有，但要折衷(又聞到了實用中庸主義的味道了吧)。如題，OO、DI、AOP、TDD和Refector正是當前的解決之道。

OO是根本，可以作為基本的“共同語言”。圖表不必要像UML那么復雜，否則最后除了分析師誰都不會看。只需要簡單建上模型，標上屬性和接口功能，最多連幾根線說明相互關系，這樣大家都懂(也就是說，這個類是個什么東西，有什么屬性，要實現些什么功能)。這種東西既可做系統說明書，也可以給開發人員，甚至生成Doc做維護文檔。
大家要說這不是“空談”嗎？要的就是空談(就好比不識字的老百姓也會談治國問題)，就是只談“有什么”和“做什么”，這樣才能有共識。但這種“空談”其實最難最費時，因為要“共識”。有了共識之后就可以下一步了。

下一步是實現。這個階段，分層、DI、AOP就可以大展本領了。Spring流行那會，大家是言必DI和AOP。可惜風頭一過，現在RoR和 Seam時尚年代，很多人大概忘了七七八八。其實筆者現在看來，分層、DI和AOP是繼OO之后最重要的思想，它們的核心在于“接口和實現分離”。這樣一來，就可以把“做什么”和“怎么做”分家，這才是它們的偉大之處。大家天天把“高內聚、低耦合”掛在嘴邊，各搞一套，亂七八糟。J2EE太復雜，大家覺得用不上。好不容易Rod推行了用得上的標準方法，大家本可以有“共同語言”了。可惜人之天生的惰性又把我們推回到“一體化”的泥潭，一代代程序員和系統就這么不了了之了。

OO還是要堅持，它是當前信息世界和現實世界實現映射的最好方法。DI和AOP也是要堅持，只有這樣才能屏蔽掉具體實現技術瘋狂變化的信息世界。堅持OO，我們才能不受數據存儲方式變化的困擾；堅持分層、ID、AOP，我們才能明確地分工合作，擺脫系統規模和事務要求變化所帶來的煩惱。

最后還有TDD和Refactor，業務在變，系統在變，我們的技術也在變。一定要能測試和重構，要能很好地測試和重構，否則系統必被變化所毀。要想能夠很好地測試和重構，如果你的系統沒有OO、分層、DI、AOP，大家是否真可以充滿底氣地回答“能”。在這一個問題上，Java是最令我放心的伙伴，而Spring更總是帶來驚喜。

DDD(領域驅動設計)是一個好的設想，而如今像Spring這類的標準化框架則可以把這個設想變為現實。在這個設想里，管理人員、分析師和用戶定義模型功能要求，架構師根據要求選擇技術方案，不同的程序員(有做dao的、做service的、做view的)根據接口要求實現代碼，通過測試后提交。而因為有支持分層、DI、AOP的框架存在(比如說Spring)，布署人員就可以簡單地把他們組裝在一起。
面對不斷的需求變化，分析師仍然只需增加/變動模型和功能接口，測試人員和編程人員按作相應變化即可。
總體設計、分步實施、按需定制、分工合作、無縫組裝，這種工業標準化的軟件開發方式才是企業應用的答案。而OO、分層、ID、AOP、TDD和Refactor是真正支撐這個開發方式的支柱。以這樣的方式，DDD會真正成為現實。

信息發達國家的軟件業其實很大程度上已經實踐了這種開發方式(想想那些大規模的外包吧)。這些年國內搞Java的，張嘴閉口便是SSH。可惜很多人搞了一些年后，還是“不識廬山真面目”，成天抱怨“好煩”。在這樣浮燥的產業環境下，國內大多數企業應用的質量是低劣的。
即使你天天在寫Java、天天在用Spring，如果不能夠“知其所以然”，那么你的SSH注定是偷工減料的豆腐渣。所以在此勸諸位從事企業應用的同道，好好靜下心來，認真思考一下你的應用所面對的各種問題，再好好思考一下OO、DI、AOP、TDD和Refator給你帶來的福音。

愿大家的系統質量都能更上一層樓，這樣才可變惡性競爭為良性合作，讓我國的信息系統發揮更大更好的作用。

posted on 2009-03-25 14:25 Joshua Yan 閱讀(201) 評論(0) 編輯收藏所屬分類: Java

新用戶注冊刷新評論列表


只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 Chat2DB C++博客博問管理
相關文章: linux 下netbeans不能使用調試功能；tomcat shutdown出現拒絕鏈接（connection refused）提示值得思考的問題寫cookie備忘超越SOA：動態業務應用的新企業應用框架（2）轉載超越SOA：動態業務應用的新企業應用框架(1) 轉載最輕便的客戶端oracle instant client安裝備忘.(轉載) 解惑 spring 嵌套事務（轉載） struts2 error (轉載) 轉載:dW 中國 2007 年 TOP 10 最受歡迎的文章和教程注意properties的使用

耐心無止境 成功一瞬間