寫測試，修改跟加代碼才快得起來。

開了這個社團，在繁體中文書拿到手之前，我可以先拋磚引玉一下。

　

《Working Effectively with Legacy Code》在我的軟體工程生涯中扮演了很重要的引導角色。

　

我個人很喜歡 chapter 2 的【Working with Feedback】，這章開頭說了，修改代碼分成兩種類型："Edit and Pray" 以及 "Cover and Modify"。

　

對於修改代碼，大家有多少信心把功能改成自己要的呢？通常不低。

　

但有多少信心，不把其他功能弄壞呢？這就很難說了。

　

大家也知道，越早發現問題，修復的成本越低。即時撰寫與執行的單元測試，就是其中一種盡早發現問題的方式。這也是為什麼在 extreme programming 中的工程實踐會被重視的原因，pair programming, TDD, Unit Test, CI 等等...

　

站在「盡早回饋」的角度，這是粒度小的單元測試比起粒度大的整合測試或驗收測試，更佔優勢的地方。這也是為什麼單元測試該由開發人員來撰寫，單元測試為什麼與產品代碼是一體的兩面。

　

在寫完產品功能邏輯的當下，應該要有能力盡快地驗證，程式是否如同預期般的執行。

　

畢竟， 「程式是照你寫的跑，不是照你想的跑」，要驗證程式有沒照你想的跑，就把你的期望寫成測試來驗證它。

　

至於，你想的是不是對的，以及你想的是不是使用者要的，那又是另外一門功課了。

　

在遺留代碼上工作，學會建立單元測試的防護網，或是先建立好安全措施，是一門必須具備的技能。

　

否則，這就像在沒有安全防護的高空上作業，「我相信你不會掉下來，我也相信你不想掉下來，但我肯定你的作業速度會因為擔心受怕而變慢或受影響。」