亚洲美女在线国产,亚洲国产精品成人午夜在线观看 ,亚洲精品理论电影在线观看

值得思考的問題

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

我們?yōu)槭裁催x擇spring（或者其他框架），為什么出現(xiàn)了IOC,AOP,ORM等等？簡單回答是“解決問題”，但他們解決不同的問題。

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

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

防止斷鏈，轉載如下：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

新用戶注冊刷新評論列表


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




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

耐心無止境成功一瞬間

常用鏈接

留言簿(3)

隨筆分類(30)

隨筆檔案(31)

文章分類(1)

文章檔案(5)

My links

搜索

最新評論

閱讀排行榜

評論排行榜

耐心無止境 成功一瞬間