posts - 6,  comments - 9,  trackbacks - 0

          這幾天總算有點時間,可以看看手頭的書了。

          手頭一直有本書從買來就沒有翻一下——《 expert one-on-one J2EE Development without EJB 》,這幾天沒事翻了一下。覺得大師就是大師一上來就把我們的苦衷說的清清楚楚,還是實踐出真理阿。

          最讓我記憶猶新的是這幾句話:

          ?

          ?????? 檢驗一個體系結構是否合理,判斷一種實現選擇是否合適,都要看他是否符合這一主旋律。

          ?????? 主旋律是:

          2??????? 簡單

          2??????? 高產

          2??????? 面向對象為本

          2??????? 業務需求至上

          2??????? 重視檢驗過程

          2??????? 重視可測試性


          所謂的主旋律,個人理解就是一種審美觀點,就像大家看到漂亮的 MM 一樣,為什么 MM 這么漂亮,因為他符合人們對漂亮的機電看法
          ——
          國色天香 傾城傾國 沉魚落雁 閉月羞花 如花似玉 花容月貌 美若天仙 艷如桃李。。。反正就是美。

          從設計模式角度說明主旋律,就是設計中常常遵守的幾點原則——可維護性,可擴展性,可復用性,要面向接口去設計,等等。

          以上這些都是從理論角度出發考慮的,而 Rod Johnson 是從實踐的角度來考慮問題,大學學了點哲學原理都運用在這里了。以前在設計第一個框架的時候沒有太多的考慮到程序員的實用型,只是為了設計而設計,最后把框架設計的及其復雜,最后的結果只有進行重新設計,進行框架的重構。而在設計中遇到的問題很多是 Rod 在書中描述的場景,真是深有感觸阿。

          2??????? 簡單

          設計中常常應該遵守 2/8 原則,系統中 80% 是最長用的,應該以這 80% 為重點去設計,如果只是為了設計中的完美而過多地考慮其他的 20% 就會陷入復雜的漩渦。就拿我們現在設計的 JBrain (我們的框架代號)框架中的元數據系統來說把,本來是為了對系統中的所有元素的一個建模過程,涉及到顯示模型建模,業務模型建模,數據模型建模,工作流模型建模,(這個就好比在基礎框架基礎上又抽象出一層),我們在建模中就是考慮到那 80% 常見的情況,對模型系統進行設計,但是每一個業務都會涉及到報表系統,這就是那 20% 的情況,如果我們再花精力去研究報表系統的建模,就會把自己帶入無比復雜的深淵中,所以我們決定用這 80% 的模型建模來描述這 20% 的報表建模,這樣問題就簡單多了,對于報表的設計來說,雖然有點麻煩,但是我們的設計可以適應大多數的情況。實際只要我們作一些輔助的工具就可以簡化報表模型的建模,這是我們在框架開發的后期發現的,經過實踐證明我們當初的想法是真確的。

          這種情況還出現在我們當初在做一個業務系統的時的框架選擇上,當時我們為了框架能夠承受更大的負載度,而考慮使用 EJB 的多層開發(幸運的是沒有用實體 Bean ),這使我們的開發量整整增加的一倍,還在不考慮測試的情況下。項目結束了上線使用,用戶根本沒有當初設想的并發量,我們當時真的還考慮了 Rod 所說的是否能夠在客戶端支持 Swing 程序,幸虧后來被否定了。有時候我們在設計中總是追尋完美,為了設計而設計,這種做法正如 Rod 所說的是不科學的。

          簡單才是美,因為簡單出現了 POJO 對象,因為簡單出現了 Hibernater ,因為簡單出現了 Annotation ,因為簡單出現了 EJB3.0 。因為簡單才是 java 的開源社區如火如荼,人聲鼎沸。

          ?

          2??????? 高產

          有時候,設計者注重的是設計,這也是我們設計中常常存在的一種習慣,程序員總是追求完美,追求 perfect ,而一個企業在完成項目中要的是生成率,要的是質量,一個功能用那種完美的框架需要 2 周的時間才能開發完,而使用簡單的框架只需要 3 天的時間就可以完成了,你說我們應該使用那種框架。

          去年在開發一個項目的時候,因為我們是和其他部門一起合作開發,在項目開始的調研當中,我們極力推薦使用我們的 JBrain 元數據框架,而另為一個部門卻強調使用 JSF 所建立的框架( JSF 剛出來,而且那個部門的人員還沒有太多的理解 JSF 的深刻含義,他們覺得 JSF 非常好,非常的完美),最后因為我們的框架是黑盒的,客戶不想把他們的項目綁死在我們的框架上,所以最后決定使用 JSF 來設計框架(不說開發一個企業級框架所需要的時間),這里我不是說 JSF 不好,我研究過 JSF ,覺得他的設計哲學真的很好,尤其他的組件樹和生命周期設計的非常完美,尤其他的 Render 機制,真的就是我們以前在使用 jsp Tag 的時候一直想要又沒有的功能(我們框架中的顯示模型有很多思想是從他的組件數概念而來的),但是如果用 jsf 開發企業級程序,而且是在國內這種客戶要求非常苛刻的情況下是非常不足的。因為我們的 JSF 框架是在 Apache MyFace 基礎上開發的,實際上后來他的標簽我們沒有用多少,大部分都是我們自己在他的基礎上重新開發的。后來框架設計出來了,生產率太低,完成一個工作需要做很多很多的事,我實在看不下去了,看著我周邊的同事一邊又一邊的嘆氣(而且項目結束前幾乎是天天加班到 9 點),根據我們原有框架的元數據原理,寫了一個 JSF 框架的代碼生成機,這才把生產率稍微提上了一點。

          實際有時候我們設計框架的時候不必要考慮過多,一定要從開發和實用的角度去考慮,多考慮一下程序員的工作方式。

          ?

          ?????? 今天就寫到這里,可能是和 Rod Without EJB 中的想法產生了共鳴才有了這么多費話,其他的感觸將在后續的隨筆中寫到。寫這篇文章也是為了提醒自己開發的時候一定要從實際出發,一切的靈感都是來源于實踐的。

          posted on 2006-05-31 23:18 我愛夏花,更愛秋葉 閱讀(1261) 評論(0)  編輯  收藏 所屬分類: 設計模式

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


          網站導航:
           
          <2006年5月>
          30123456
          78910111213
          14151617181920
          21222324252627
          28293031123
          45678910

          又回到了夏花的時節了!我又回來了:)

          常用鏈接

          留言簿(1)

          隨筆分類

          隨筆檔案

          不錯的blog

          不錯的網站

          搜索

          •  

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 洪泽县| 博兴县| 芒康县| 巨野县| 关岭| 浑源县| 灵寿县| 阿拉善盟| 北海市| 呈贡县| 自治县| 绍兴县| 泌阳县| 连南| 白朗县| 溧水县| 西和县| 兴国县| 出国| 德化县| 渭源县| 江都市| 罗江县| 怀仁县| 百色市| 永川市| 莎车县| 甘德县| 芷江| 桑日县| 漾濞| 东乌| 灵川县| 阳江市| 临武县| 文昌市| 偃师市| 建湖县| 格尔木市| 开封市| 平定县|