專案控管：JavaEE還是Spring Framework?

這個題目其實我已經想了很久，不過最近看到的一個Case又讓我覺得不能不寫一下這方面的想法。一個完整的軟體專案必須考慮到的因素當然很多，除去掉PMP那些必然會提到的因素之外，我個人認為專案經理仍然必須將一些開發前、中、後的因素加以仔細的考量，並且以宏觀的技術角度來思考整個專案成敗的問題。

不管是PMP或者CMMI都相當強調風險的控管，殊不知風險的預估可不像是人壽保險那樣有客觀的統計數據作為依據。如果無法掌握手中的技術，風險這種無形的東西並不是能夠委外的。實際上要思考的方向應該是，如何動用手上所有的技術和工具來讓軟體專案的風險能夠降低。

以我的標題作為例子，目前Spring Framework是門顯學。我應該是在台灣使用Spring Framework的先驅吧！我當然可以理解這樣技術的便利性。不過便利性不代表不需要了解底層內容。以Connection Pool為例，目前Developer都有使用Apache DBCP的概念；不過許多Developer所忘記的是，Connection Pool仍然是一種基於TCP/IP Socket的一種技術。Socket並不是可靠的、永久存在的，所以完整的Connection Pool實作往往都會搭配一些測試參數以確保Connection要用的時候仍然是可用的。舉例來說，BEA WebLogic Server的Connection Pool能設定每一段時間就對資料庫進行測試查詢，讓資料庫的連線不至於因為idle而被防火牆移除。就以Apache DBCP來講，這樣的參數也是存在的。重點是，了解這些底層的細節其實是開發人員應該要能夠Handle的事情；而專案經理必須知道這種問題會發生。Code並不是只要Work就好；系統是必須經過時間的考驗的。既然已經使用了WebLogic，那開發的角度應該是要將Application Server的特性考慮進去；不然應該就要有把握能夠使用Framework之後不會有問題。

事實上，Springframework其中一個大好處就是它的ApplicationContext.xml。只要設定更改了，Code完全不動的情況下，就可以將DBCP Connction Pool改成WebLogic的Connection Pool。透過這樣的做法，Unit test的時候還是可以使用個人的資料庫在不啟動Application Server的狀況下進行資料查詢邏輯的測試，然後在上線測試的時候再改成WebLogic的Connection Pool。Springframework的一個宗旨就是要讓開發能夠Scale up and down easily。使用它而沒有參透它的精神那就太可惜了。要記住，Springframework只是拿來掩蓋掉JavaEE的複雜度；身為一個負責任的開發人員或者專案經理，你還是必須對底層的技術有所了解。你所不了解的，就會是你的風險；這是無庸置疑的。

Powered by ScribeFire.