Dec. 11 17:39~18:50
TDD (Test Driven Development)
Emerson在課程中有介紹TDD（測試驅動開發）的概念，但是他介紹的方式是從維護legacy code（遺留程式碼）談起。如下圖所示，假設鄉民們要去修改legacy code裡面的某項功能，修改功能本身也許並不困難，但最怕的就是改了之後原本可以動的功能變得有問題而且自己還不知道。
在這種情況之下，可以先幫準備修改的這個功能撰寫（補寫）測試案例（下圖黃色的小圈圈）。只要是這個準備修改的功能和系統其他部分有互動的地方，都要測試。寫完這些測試之後，等於幫這個功能建立起一個安全網，接下來就可以放心地修改功能。
如下圖所示，整個開發的流程變成（1）先寫測試、（2）實作功能、（3）設計/重構，這樣的開發順序剛好和傳統的Waterfall模式相反（在Waterfall模式中，先設計，再實作，最後才是測試）。
***
為什麼要舉Legacy Code的例子
一般提到TDD的概念，都就：
- 在開發功能之前，先幫這個功能寫一個測試案例。由於production code（功能）還沒開發出來，所以這個測試案例一定會失敗。
- 實作功能。
- 利用重構來達到改善設計的目的。
以上三點，和剛剛用legacy code所舉的例子幾乎一樣，除了以下這一點不同：
- 在legacy code的範例中，一開始寫出來的測試案例是會通過的。
也就是說，採用TDD方式來修改legacy code，提供一個比較具體的context（情境），讓補寫測試案例這件工作融入開發流程之中。看到這邊鄉民們可能會想：「標準的TDD也是讓寫測試這件事融入開發流程之中啊？」沒錯，但是對於某些開發人員而言，在production code還沒出現之前要他們先把測試案例給寫出來，是一件很痛苦的事。但是如果從legacy code的角度切入，由於原本已經有一份可以動的production code存在，先幫這些production code寫測試，以避免之後的修改造成不可知的錯誤，希望用這種切入角度來降低開發人員的抗拒。
***
最後Emerson介紹學員可以參考《Working Effectively with Legacy Code》。這本書Teddy之前也有介紹過，是一本可以提供開發功力的好書，值得一讀。
***
友藏內心獨白：好像快沒東西可以寫了 
沒有留言:
張貼留言