Search
我們開始有些討論囉。
這書的原始出版日期是 2004 年，有一些詞彙並不像現在比較被普遍使用，甚至已經是 convention 了。
也有一些是作者刻意不先用一些「詞彙」來掉書包，而是用描述 context 的方式來說明，為什麼我們會需要這些東西，而這些東西就是常見的某個「詞彙」。
看書卡彈很正常，尤其是實務上沒有其他知識領域互相搭配或實際打仗經驗，容易被單點卡住。
歡迎大家討論，也歡迎大家用新台幣支持天瓏跟博碩。
當然，也很歡迎來明年二月的課：【針對遺留代碼加入單元測試的藝術】
>> https://dotblogs.com.tw/…/unit-testing-effectively-with-leg…
這門課就是針對 legacy code + isolated unit test 兩個核心，透過實務演練來說明書裡的精華。
真要說參考書，就是：
① Working Effectively with Legacy Code
② The Art of Unit Test - 2nd edition
不太理解第三章裡面這個 "感測" 指的是什麼意思 ? 🧐
寫測試，修改跟加代碼才快得起來。
開了這個社團，在繁體中文書拿到手之前，我可以先拋磚引玉一下。
《Working Effectively with Legacy Code》在我的軟體工程生涯中扮演了很重要的引導角色。
我個人很喜歡 chapter 2 的【Working with Feedback】，這章開頭說了，修改代碼分成兩種類型："Edit and Pray" 以及 "Cover and Modify"。
對於修改代碼，大家有多少信心把功能改成自己要的呢？通常不低。
但有多少信心，不把其他功能弄壞呢？這就很難說了。
大家也知道，越早發現問題，修復的成本越低。即時撰寫與執行的單元測試，就是其中一種盡早發現問題的方式。這也是為什麼在 extreme programming 中的工程實踐會被重視的原因，pair programming, TDD, Unit Test, CI 等等...
站在「盡早回饋」的角度，這是粒度小的單元測試比起粒度大的整合測試或驗收測試，更佔優勢的地方。這也是為什麼單元測試該由開發人員來撰寫，單元測試為什麼與產品代碼是一體的兩面。
在寫完產品功能邏輯的當下，應該要有能力盡快地驗證，程式是否如同預期般的執行。
畢竟， 「程式是照你寫的跑，不是照你想的跑」，要驗證程式有沒照你想的跑，就把你的期望寫成測試來驗證它。
至於，你想的是不是對的，以及你想的是不是使用者要的，那又是另外一門功課了。
在遺留代碼上工作，學會建立單元測試的防護網，或是先建立好安全措施，是一門必須具備的技能。
否則，這就像在沒有安全防護的高空上作業，「我相信你不會掉下來，我也相信你不想掉下來，但我肯定你的作業速度會因為擔心受怕而變慢或受影響。」
喔喔喔喔！沒想到博碩談到版權，再次出版了 Working Effectively with Legacy Code 的繁體中文書了！
>> https://www.tenlong.com.tw/products/9789864344000
我推薦的重構三部曲：
① Working Effectively with Legacy Code
② Refactoring
③ Refactoring to Patterns
原本三本的簡體、繁體中文都絕版了（當然，Refactoring 是推出新版）
現在最難買到的 Working Effectively with Legacy Code 就沒這問題啦，無疑是一大福音。
對我來說，先看這一本，再看 Martin Fowler 的 Refactoring 會更順一點。
畢竟， Working Effectively with Legacy Code 帶到了蠻多「在無測試保護的情況下，如果用低風險的手法重構」
沒啥好說的了，先訂個 30 本來當學員贈書就對了。
※ 用新台幣支持 天瓏資訊圖書 跟 博碩 就對啦！
※ 兵貴神速，已經建立完成這本書的閱讀交流社團：https://www.facebook.com/groups/342463580015957/
working effectively with legacy code 在 《Working Effectively with Legacy Code》閱讀交流 - Facebook 的必吃
《Working Effectively with Legacy Code》是一本經典好書，在重構的學習上，我推薦的三本經典書籍以及順序是： ① Working Effectively with Legacy Code ② ... ... <看更多>