04 January 2006

今個兒我發了封 mail 給我們的 team,裡面有一些構想可以跟大家一起分享


All,

我建議未來的、或現今的大小 Project 都應該已 spring 為基礎來建立,原因如下:

(1) 避免重新發明輪子

Spring 的開發人員已經寫了很多工具,能夠用專家寫好的工具總是比較安心的,而且它的工具全世界的人都在用,保證沒問題的啦!

我們 team 內並沒有一個 util 的子計畫,來收集整合我們常用的工具,所以能夠用別人寫好,整理好的,自然會比較省事。

(2) Spring 會統整其他 library

試問大家現在用的 commons-lang, poi, log4j 是哪一版的,大家有概念嗎?hibernate 3.0 所用的 commons 和 Struts 1.2.7 用的 commons 的版本一樣嗎?如果兩個不相容怎麼辦?

這種 library 版次的問題,從 vb, c++ 到 java 都有。Spring 本身就整合了許多 library,Spring 的每個 release 都會做相容的測試。所以如果我們要用某某 library ,那就先去找 Spring 裡整合好的,用 Spring 整合的 poi 啦, log4j 啦... 可以省去 我們的麻煩。當然這只是基本原則,有時候 Spring 提供的並不會太新,而舊版的 lib 有 bug 或是我們想用新版的功能,那麼還是可以自己抓更新的版本,只不過 這時相容性的問題就要自己煩惱了。

(3) 新進人員只需熟悉一種架構、一種寫法即可

我們 team 採用相當多的 open source framework,但這些都不是 "標準" 。 不像 servlet、jsp 等等 都是標準,比較廣為人知。在 java 界裡,通常同一種功 能有好幾種 open source framework 可以選。那麼該選哪一個? 當你在選這些工具時,你不能只考慮這個工具適不適合你這個專案使用,你還要 考慮這個工具是不是:

  • (a) team 裡面已經有人先選了一種 -- 這時你可以先問他用起來如何,然後再做打算
  • (b) 這個工具在 java 界是不是較多人在用?有沒有一直在更新?
  • (c) 簡單好學

(a) 條件是我們必需優先考慮的部份,team 裡面用兩種以上的工具只會讓我們的 維護及學習上更加困難。所以第一個選 framework 的人很重要,他就要評估 (b) 和 (c) 兩個項目。如果你選 Spring 的版本,那基本上就直接符合 (b) 和 (c) 了,而且 Spring 都會替這些 framework 附加一些工具,而那些工具的架構、寫法基本上都差不多 (多半是 template/callback 的寫法)。

所以優先考慮 Spring 的提供的解決方案,是比較簡單的選擇,而且對我們 team 整體本身比較好。

切記:選 framework/工具 時,請顧慮到以後接手維護你專案的人,除非你手上的專案用完就丟了,那麼你大可以任意嘗試新東西。

(4) Spring 的東西通常比較好測

Java 有很多 framework,但是把 "好不好測" 當做設計條件的沒幾個,而且通常很舊的framework 的可測試性都很差。選擇 Spring 的版本,通常就是保證測試好寫 (因為 Spring都會先寫測試了)。

其他:

如果是小計畫要不要用 Spring?計畫這麼小用 Spring 不是殺雞用牛刀嗎?我們應該因應計畫的特性、大小來選擇合適的工具不是嗎?

這個問題,我建議的答案還是要的,因為小計畫通常是新進人員的練習平台,這正是他們熟悉大專案的最佳時機。小計畫用 Spring 寫法練習,那麼到了大專案就很快就熟悉了。雖然小專案被複雜化了,但是長期而言,對整個 team 會比較好。

註:以 Spring 為基礎的意思是:當 Spring 提供了你需要的功能,例如 mail, schedular, remote, persistence 等等附加功能時,我們要優先 使用 Spring 所寫的功能。現階段我們不用 Spring 的地方只有 Spring MVC... 因為他比 Struts 沒好到哪裡去,用了只會增加我們的學習 以及維護門檻。

ok, 就這樣,歡迎其他有關架構/framework上的建議



回響

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