星期六, 11月 11, 2006

軟體要活著

好吧,我承認標題是在騙人,這年頭總要誇張一點才有人要看。雖然我的Blog PageRank是2,但是瀏覽率低得不像話,counter是自己灌水的。這篇主要是給不熟悉XP的人看。

Martin Fowler說,軟體要一直改版才會一直生存下去。(大概是這個意思啦,原文我忘了)

軟體必須要隨時不斷地變動才能存活,原因如下:

軟體不可能不變,需求是會不斷地改變。
假設需求很穩定不變;就算程式碼(source code)不變動,程式語言也會變;程式語言不變,編譯器也會變,編譯器不變,作業系統也會變,作業系統不變,硬體也會變。最後因為硬體更新->作業系統更新->編譯器更新->程式語言更新->程式碼更新。

當然現在有Virtual Machine,可能在某些MIS的堅持下能省一些功。但是人性的貪婪讓使用者想要整合所有的資訊,並不是躲在象牙塔裏就沒事。若貴公司還在用VAX,大概也找不到能夠用的VM吧?或者是老板某天想要你把出勤資料做一個報表,但是現在已經沒有人看得懂VAX上的COBOL... 最慘的是VAX硬體故障,廠商也沒有備料... (It's true now!)

另一個情境假設你使用NT 4.0+ IIS 2.0,用asp 1.0寫程式,某天系統工程師手癢升級到Windows 2000,結果逼得你不得不升級,以前用class做為asp變數名稱的頁面全發生錯誤...只好含著眼淚慢慢地debug。


我剛開始工作時也很討厭接舊專案,連改自己的程式都不太願意,每天都想玩新東西,後來看了Refactoring這本書後,漸漸改變自己的想法。試想:你在一間公司當MIS,人事、薪資、保險、出勤等系統都需要穩定執行,但也需要新功能的加入與維護;這些東西才是IBM等大公司想賺的部份:維護費。

改變成本

軟體改變的成本如上圖,所以說,要盡量在上線前做好,但上線後的改變呢?
eXtreme Programming 的創始人Kent Beck(他總是讓我想到Can't Back,鼓勵人們把握時光?)是一名資深的PM、顧問,從SmallTalk到C++、Java,經歷無數的專案,因此他提出的理論可以與實務結合,與 純學術派的學者不同。XP中我最早接觸的就是Refactoring,接著是Unit Test,這些都是很實用的技巧。

要保持軟體經常性的修改,就需要Unit Test來降低改變的風險與變數。有些人搞不清楚Unit Test與Functional Test,Unit Test的最小單位是function,而Functional Test是指規格書上的某項功能;當元件化之後,自然地就以Unit為單位Test。每次小修改,都有可能引起未知的災難,所以就算是只對某個API更改,仍然必須做完整的TestCase。目前在許多的平台上都有Unit Test的framework,找一個自己喜歡的吧!再配合Refactoring的技巧,熟悉後就能夠習慣快速改版的生活。

沒有留言: