好吧，我承認標題是在騙人，這年頭總要誇張一點才有人要看。雖然我的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的技巧，熟悉後就能夠習慣快速改版的生活。
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的技巧，熟悉後就能夠習慣快速改版的生活。
留言