堅持發揚EJB、Spring的光輝思想，將元件化進行到底！

lgx522發表於2007-05-21
Spring元件化
好大的標題，看似又一篇炒作濫文，其實是筆者近兩年對軟體架構痛苦思索徘徊後所得的經驗體會，在此與諸位共勉。

EJB、Spring，這不是Java界最有名的兩大冤家，何以把它們扯在一起。其實Spring乃是EJB1.x、2.x的繼承者，正如EJB之前的COM、CORBA。他們的思想一脈相承，那就是企業級的元件化思想，也可稱之為理想！

一、非元件化的國內軟體行業

各個行業的企業總有一些核心業務，長久保持不變，新時期的新業務基本上都是圍繞核心業務展開。很長時間以來，IT技術的變化與企業業務的擴充套件存在著很大的矛盾。當企業的新業務開展之後，如何保證原有業務穩定執行的同時，新業務能夠得到IT的支援與擴充套件？當IT技術有重大進展後，如何保證原有業務的同時進行新技術改造？在以上兩種運動中，如何重用原有的技術成果？這是每一位負責任的系統管理員、CIO與及開發商所關心的事情。遺憾的是，元件化思想及實踐產生以前，這個矛盾基本上是極難解開的死結。絕大多數的做法就是重寫。
譬如DOS時代，很多單位都使用了單機foxbase版的財務系統，介面雖簡但穩定實用；到了Windows時代，流行VB、PB，於是系統重寫；再到B/S時代，系統再次重寫；到最近熱炒的RIA，系統是不是要再次重寫？對於很多小產商的作品而言，答案肯定是Yes。
很多同道可能會說，這樣正好啊？我們才可以不斷地賺錢。錯！
這樣的狀況叫“低水平重複”，這個術語經常被國人用來痛斥社會經濟領域的很多不合理現象。可惜我們這個自認為高智力的行業，很多時候就是在幹這種愚事。每到技術革新，各企業要重花一次錢、重學一次操作、重轉一次資料，折騰得半死；而適應不了新技術的產商，隨被淘汰的程式碼一同退出市場；適應不了新技術的程式設計師，只能轉行。要想不被淘汰，就必須緊跟時代風潮，不停地把精力放在新技術上，在領會業務上花的時間太少，最後導致我們的系統與企業的業務總是差半拍。因為原先快把業務搞清楚的程式設計師大多升官或離職了。
筆者以為這是軟體界，尤其是國內軟體界混亂的根本技術原因。由於技術長期得不到積累，我們不得不一次又一次吃外國的人剩飯。

那我們終究需要怎樣的軟體才能解決這些問題。
其實答案早就在我們身邊晃了太多年，偏偏我們視而不見。大家接個新外設，要不要換主機？加根記憶體條、換塊顯示卡、音效卡要不要換主機板？OS是不是隻能用幾個特定的硬體，跑幾個特定的程式？而大家在OS下寫的程式，是不是在系統新版本執行不了？答案基本上是否定的。
OS可以適應全世界數以萬計的程式及其發展，為什麼我們的應用程式不能適應哪怕一個特定單位的變化和發展。為什麼我們的應用系統到了新環境下就要重寫？
原因就在於我們大多數應用程式規範性太低、耦合度太高。

要提高規範性、降低耦合度，就要不斷地設計、不斷地分層、不斷地抽象、不斷地重構。當我們終有一日把有用和成熟的程式碼封裝成jar或是dll，不僅自己能重用，別人也能重用的時候，程式碼其實才算合格。
現在大家都習慣用開源產品了，外國人熱衷的就是不斷地製造這樣的零件（元件）或技術。而我們中國人，熱衷的卻是組裝人家的零件和技術（一如其它涉及技術的產業）。很多外國人十多歲就做出了了不起的元件，而我們中國人卻把“不重複發明輪子”這種搬來的話掛在嘴在，結果是既不製造舊輪子，更沒有能力發明新輪子。很多人從業十多年都寫著亂糟糟程式碼。
專案，不是說東西扔到客戶手上套足了錢，拍拍屁股就走人。成功的專案，要對客戶負責任。就算自己退了，也該把工作交接好。前面的工作成果後面用不上，只能說前面的工作不合格。
國內應用軟體界一直在走RAD的道路，一開始吃著爽，越到後面越不是滋味。不是說RAD不能用，而是說，一上來就RAD，註定被養成懶漢，早晚淪落成編碼機器。RAD誘使我們逃避思考，誘使我們逃避設計，最終讓我們被早早淘汰！

相關文章