當你接受一個遺留系統被賦予新增功能的任務時，首先，你會去看看原始碼，糟糕，原始碼一團亂，怎麼辦呢？是重構後加入新功能，還是另外寫新功能不要去碰觸舊有的程式碼呢？面對運行了許久的大型遺留系統，工程師常常糾結在「改」還是「不改」的抉擇中？而在大多數的情況下，台灣的工程師總是決定對於遺留系統採取容忍的態度，一忍再忍，再忍，忍，還要忍……終於累積到了某一天，實在是忍無可忍時，拍案而起，不能再忍了，終於喊出「我要重構！！！」事情就這樣發生了。然而，此時你會突然發現，重構的工作千頭萬緒，不知從何開始。
還是回頭拿起書架裡的重構教科書來看看吧，就是那本由兩位大師MartinFowler,KentBeck和其他三人合寫的《Refactoring:ImprovingtheDesignofExistingCode》，想要在其中找找看怎樣來重構比較妥當。這本重構經典書告訴你，要重構就不能把原有功能給破壞了，所以在開始重構之前，首先應建立起「自動化測試」。好的，那我們就去打開測試程式吧！什麼，遺留系統沒有測試程式，那該怎麼辦呢？遺留系統不是用TDD開發的，那…那，我們要怎樣重構才能保證原有功能不會出錯呢？慘了，在第一關就卡住了。硬著頭皮幹吧，反正就是另外再寫新功能，不要去動到舊有的程式碼就對了。是的，這就是現實中大多數台灣工程師的作法。可是這樣做，程式碼的品質就越來越差了，不論是自己後面要再加新功能或者是丟給別人來接手，無疑都是場災難。
回過頭來說，那本重構經典書不就英雄無用武之地了嗎？嗯，雖然那本書寫得很好，但是不夠本土化。先來看看台灣的環境吧，在台灣開發軟體，起初都是工作室型態的，用最快的速度、最少的人力，開發出滿足客戶需求的軟體，快速上線運行就OK了。什麼程式碼品質，什麼可讀、可維護、易變更，全都不用考慮。別說測試程式碼，就是程式碼可測性都沒有人會去考慮。這樣的方式讓軟體開發公司快速拿到了第一桶金，但為日後的維護與軟體發展帶來了隱憂。而在美國情況完全不是這樣子的，寫程式就是該寫品質好的程式碼，就是該有測試，所以該書假設的前提都是對的，故而如何讓遺留系統建立起「自動化測試」，大師在書中隻字未提。換句話說，重構經典書的前提不適用於台灣。我們需要的是一本真正適用於台灣真實情況的重構書籍，而《大話重構》就是您最佳的選擇。也因此，本書被列為博碩文化《中文原創經典》的第一本書。
本書把常見的，如抽取類別、抽取方法、用多型取代條件等等數十種重構手法全部都放到附錄中（這些手法我們稱之為重構工具箱），因為那些在別本重構書籍裡通通查得到。本書當然也會提到那些工具，但並非本書的重點。本書要講的是重構的觀念（例如何時重構）、如何一步一步地重構，如何面對遺留系統，如何說服老闆來重構，本書所提的是一種系統與設計層級的重構，而非單單只是程式碼層級的重構。
本書會以真實的遺留系統案例，來親自示範如何一步一步地重構，直到這個系統可以輕鬆應付未來的變更。同時，本書也強調許多觀念，例如不要做大佈局，因為『大佈局，你傷不起！』，本書強調只做今天的設計，解決今天的問題，完成今天的重構，讓明天見鬼去吧。因為你不是先知，你無法預測未來，做過多的設計是在浪費時間，要做的是『好的設計』而非『過多的設計』。什麼是『好的設計』，那就是明確地分層解耦，讓你的系統很可很輕鬆地面對將來未知的需求變更。
本書作者的程式與設計功力深厚，但撰寫這本書時，常常能夠站在基層工程師的角度出發，例如，對於大多數老闆而言，重構沒有立即效益，所以要如何說服老闆對遺留系統進行重構給予支持，才是重構得以實行的關鍵。只要你有『一點點』設計模式的底子，相信這本書會協助您解決許多正面臨的困難。
本書既稱之為『大話』重構，自然在文字用語上會有一些特色，以下舉幾個經典例句：
■「小步快跑」
■糟糕設計零容忍！
■小設計可以讓你獲得成功！
■自動化測試——想說愛你不容易
■系統重構最後的一里路——測試的困境。
■活在當下，設計今天的程式，讓明天的變化見鬼去吧！
■測試與重構形成了一個「雞生蛋，還是蛋生雞」的奇怪循環。
■合久必分，分久必合——類別的歸併
■領域才是軟體系統的「心」！
■開發糟糕程式碼是可恥的！
■大佈局你傷不起！
■「兩頂帽子」
這本書是一本關於重構，實踐經驗分享的書，至於這本書能夠帶給您多少的領悟，還得由您細細體會。
