大師之間的不謀而合
相信從事軟體開發的從業人員應該都聽說過TDD (測試驅動開發)，如果不知道什麼是TDD的話，基本可以簡單理解成：
在編寫函數之前，先寫好相關的測試案例
最近一個月我強迫自己用TDD的方式來寫程式，突然發現TDD這個方法與這兩年很紅的一本書 — 原子習慣 有不謀而合之處。
這邊簡單說明一下原子習慣的概念：
把習慣切成十分微小的要求，就會發現培養好習慣是相當容易的事。
作者提供了四個法則讓大家容易培養出原子習慣，而我發現似乎能把這四項原則跟TDD的開發概念互相呼應。
法則1：讓提示顯而易見
法則2：讓習慣有吸引力
法則3：讓行動輕而易舉法則4：讓獎賞令人滿足
我相信許多人在開發新功能時，常會有一頭霧水的情況。面對要做的功能太多，會有無所適從的感覺。例如你可能只是單純打個API要做資料處理，但其實裏頭的功能遠比你表面看上去複雜。
你會有一個發送API請求的功能，要回來的資料可能是JSON或是XML等之類的格式，而你需要讀取這個response裡面的資料，再來你可能只需要其中的某些資料，所以你必須對資料進行過濾，當你拿完資料可能還要做個分類或是依照其內容作一些編排，最後輸出檔案可能還有不同格式。
那這樣可以大概細數一下有哪幾項功能：
- 對API發送request
- 解析回來的response (可能有不同格式)
- 過濾資料
- 分類或加工資料
- 轉換格式(可能是CSV、JSON或是任何特定格式)
- 輸出至檔案或報表
最糟糕的做法大概就是只用一兩個函數處理掉這所有的事，可能就把1–3放一個函數，4-6放一個函數，中間的介面可能是一個string 或 list。大概是大學生作業等級的東西…
但如果是有點經驗的工程師就會知道，這些程式碼可不是作業 — 交出去就再也見不到它了。你可能會面對需求的修改、新增，所以你需要將各項功能分開以便來日重複使用，對於修改程式碼你也省得一口氣看500 行程式碼，你只需要專注在你要修改的部分，可能也就20行而已。
如果你寫程式的時候，沒有設想到這些未來情況，隨便產了一坨糞code出來，那這坨屎很有可能是幾個月後甚至是幾年後的你來吃。
但要怎麼確保你的設計是足夠彈性 — 至少彈性到幾個月後的你還看得懂，而且也改的動。
你需要寫測試
嗯…
那好，既然我們都知道要寫測試了，那什麼時候寫？
你終究要寫測試的
那為什麼不一開始就寫？
好巧！回到了我們的主題TDD，藉由先編寫測試來驅動開發有那些優點呢？
- 讓你能夠從呼叫者的角度去考慮程式的設計。呼叫者可能是任何人 — 你或其他工程師。為了everybody著想，避免重工或無意義的修改，從呼叫者的角度考慮程式設計是相當好的。
畢竟，早知如此何必當初呢 - 及早處理例外情況。如果你的參數是浮點數，但呼叫者傳了整數進來，你要怎麼辦？丟例外；幫忙處理型別轉換？
AKA 超前部屬 - 讓函數變得足夠小。小巧的函數才能夠方便你測試，方便測試也就意味著更容易偵錯。
時間就是金錢，同時也是你的生命 - 更容易重構。當你發現當初的作法不夠好時，你可以放心的進行優化，因為你有測試在保護你。
Just do it.
但這跟原子習慣有啥關係呢？
回憶一下我們培養的原子習慣四條法則：
法則1：讓提示顯而易見
在有測試案例的情況下，你的腦袋不會漫無目的發散性思考。你要做的事情很單純也很簡單，寫出能夠通過測試案例的函數，這能夠幫助你專心。
法則2：讓習慣有吸引力
在你寫好測試案例之後，先執行一次。
沒錯！一定會失敗。所以我相信你會更有動力去編寫函數。畢竟整排的 test case failed可不是讓人心曠神怡的事情。
法則3：讓行動輕而易舉
為了設計出容易測試的函數，你會把函數功能設計的足夠簡單，這會讓你編寫一個函數可能只花兩分鐘，這麼簡單輕鬆的事情沒道理拖延吧？
法則4：讓獎賞令人滿足
看到一整排的測試案例從failed 變成 passed。相信我，這挺令人舒壓的；除此之外，看到自己正往著正確的軟體工程之路前進，你的心裡會十分的充實、安心。
