17 August 2005

又到了一年一度的 Java Two 大會啦,今年照例有閃閃亮亮的 Java Girl,個個穿的像輕飄飄的仙女... orz 可能是我老了吧,對這種打扮過度的提不起什麼勁... (還是我還不夠老?!)。Anyway 早上一開場就是東吳國標舞社團帶來的熱辣森巴舞蹈,呃... Java 跟這個有什麼xxx.... ...還真有點突兀,但辣妹們奮力地扭腰擺臀到是不錯的提神劑啊~~ 緊接著卻是大官們的八股致詞... 馬上 orz... 雖然能聽到 Java 超高的應用數字還是令人感到無比欣慰,十年有成啊!

這一次請來了兩個原廠的員工,第一個是 Matt,講 Sun 在 open source 和開發環境的策略和企圖心.... 老實說儘管 Sun 的新動作很多、Open 的 source 也很多、IDE 投注的心力也很多... 但實際上為什麼一直不賺錢?不被開發者認同?IDE 沒啥人用呢?背後的原因也許很複雜吧... 個人倒是覺得最大的原因是:Sun 並沒有聽開發人員真正的心聲

另一個員工 Rima (?) 講的是 Java ME,這不是個人專長的領域,又是講英文,聽的霧煞煞... 最後,在有限的時間之內,Moli 把這兩天的要講的議題用幾個主題串接起來,大致地介紹了一遍。短時間內講的有調有理真的算很厲害了,但也狠狠地桶了講師幾刀。呵呵

第一個議題我選了 C-JDBC,這玩意以前曾k 過一些資料,後來發現不符需求就沒有試了。這一次希望能夠聽到實務的經驗... 可惜講師只準備了概念性的介紹... 而實務上像是 RAIDb 能夠增加多少效能啦,各種異質資料庫混用時要注意的地方等等比較重要的議題,就沒有提到了,而後來 live demo 也掛了。哎...

第二個議題選了 Java / .Net inter-operation。聽 Browser 轉述 Moli 說:講師李宗達乃 "神人" 也。好奇心趨使下就選了這個議題 (本來跟 .Net 有關的不大想碰)。一聽之下,乖乖,果然是神級的人物啊!inter-op分類的很清楚哪,總共四種作法:一是靠資料庫、二是靠 message、三是靠 runtime bridge、四是靠 adaptor ,各有優劣。講師也不唱高調,只拿真正有用的 solution 出來講,因此也談了一些 SOA、Web Service。雖然之前一直對這種東西很感冒,但聽講師這樣分析下來,沒這玩意還真難把系統給兜起來。後來的 Live demo,即使時間不大夠,中途還是寫了個小 JUnit,而不省去 Unit Test 這個重要的步驟。而可以 Unit Test,也代表這個 solution 是 POJO-aware 的。看了大是另人感動,此公真乃我輩中人啊!

最後一個議題選了 J2EE Anti-Pattern,講師慢調思理的風格跟上一場完全相反 (上一場東西多,又快)。雖然名為 J2EE Anti-pattern ,不過內容比較 general 一點,跟 J2EE 沒啥直接關係。他提到一個重點: Anti-pattern 多半靠管理層面來解決。這一點過去到是從來沒有想到... 嗯,其實這句可以更廣泛的解釋:任何專案失敗都得靠管理來解決 -- 有人程式寫不好,造成專案失敗,其實不管是他程式是哪種爛法,管理者都得花精神去處理這個人的問題,不然他就只有一直爛下去,下個專案再度失敗....;如果架構爛,表示沒有人有經驗、或是技術差、又或者是上位者根本就是眼睛瞎了,毫無遠見... 這當然也只有管理階層能解決;如果管理出了問題... 這個就不用說了,當然只有管理的人他們自己能解決了。大方向是由管理層面來負責,而實際上解決的方法、手段則需依各種症狀下藥,探討 Anti-pattern 就是探討病症以及如何下藥。

對於 Anti-pattern,講師提到是用 iterative 的方式來解決,而 design pattern 則是一次性的、完整設計好就採用。前者沒錯,refactoring 的確是漸近,iterative的;但是對於 design pattern 的觀念就不大對了。Design Pattern 並不是一次性的,他也是 iterative 的。講師在會議中不時提到,按照正統 RUP/UML 規畫設計,就可以得到良好的 OOP 設計,不然就會淪落為 structured, non-OOP 設計。這種說法並不完全正確... 除非這個系統已經做過好多次了,而且變化不大,不然按照 正統 RUP/UML,得到的 OOP / design pattern 只能算是半成品而已,甚至是完全 "套用錯了"。

    "相信一次性的設計就能搞定,這個想法本身就是個 AntiPattern"

要解決這個 AntiPattern,就是重新思考 design pattern 的運用 -- 運用 design pattern 是 iterative的,它隨著使用者需求的增減變化,經過數次的 refactoring,才會漸漸成形。這個作法再廣義一點也可以應用在一般 OOP 的設計上。


回響

可以用 Tag <I>、<B>,程式碼請用 <PRE>