大話重構

<內容簡介>

當你接受一個遺留系統被賦予新增功能的任務時，首先，你會去看看原始碼，糟糕，原始碼一團亂，怎麼辦呢？是重構後加入新功能，還是另外寫新功能不要去碰觸舊有的程式碼呢？ 面對運行了許久的大型遺留系統，工程師常常糾結在「改」還是「不改」的抉擇中？而在大多數的情況下，台灣的工程師總是決定對於遺留系統採取容忍的態度，一忍再忍，再忍，忍，還要忍……終於累積到了某一天，實在是忍無可忍時，拍案而起，不能再忍了，終於喊出「我要重構！！！」事情就這樣發生了。然而，此時你會突然發現，重構的工作千頭萬緒，不知從何開始。
還是回頭拿起書架裡的重構教科書來看看吧，就是那本由兩位大師Martin Fowler, Kent Beck和其他三人合寫的《Refactoring: Improving the Design of Existing Code》，想要在其中找找看怎樣來重構比較妥當。這本重構經典書告訴你，要重構就不能把原有功能給破壞了，所以在開始重構之前，首先應建立起「自動化測試」。好的，那我們就去打開測試程式吧！什麼，遺留系統沒有測試程式，那該怎麼辦呢？遺留系統不是用TDD開發的，那…那，我們要怎樣重構才能保證原有功能不會出錯呢？慘了，在第一關就卡住了。硬著頭皮幹吧，反正就是另外再寫新功能，不要去動到舊有的程式碼就對了。是的，這就是現實中大多數台灣工程師的作法。可是這樣做，程式碼的品質就越來越差了，不論是自己後面要再加新功能或者是丟給別人來接手，無疑都是場災難。
回過頭來說，那本重構經典書不就英雄無用武之地了嗎？嗯，雖然那本書寫得很好，但是不夠本土化。先來看看台灣的環境吧，在台灣開發軟體，起初都是工作室型態的，用最快的速度、最少的人力，開發出滿足客戶需求的軟體，快速上線運行就OK了。什麼程式碼品質，什麼可讀、可維護、易變更，全都不用考慮。別說測試程式碼，就是程式碼可測性都沒有人會去考慮。這樣的方式讓軟體開發公司快速拿到了第一桶金，但為日後的維護與軟體發展帶來了隱憂。而在美國情況完全不是這樣子的，寫程式就是該寫品質好的程式碼，就是該有測試，所以該書假設的前提都是對的，故而如何讓遺留系統建立起「自動化測試」，大師在書中隻字未提。換句話說，重構經典書的前提不適用於台灣。我們需要的是一本真正適用於台灣真實情況的重構書籍，而《大話重構》就是您最佳的選擇。也因此，本書被列為博碩文化《中文原創經典》的第一本書。

本書把常見的，如抽取類別、抽取方法、用多型取代條件等等數十種重構手法全部都放到附錄中（這些手法我們稱之為重構工具箱），因為那些在別本重構書籍裡通通查得到。本書當然也會提到那些工具，但並非本書的重點。本書要講的是重構的觀念（例如何時重構）、如何一步一步地重構，如何面對遺留系統，如何說服老闆來重構，本書所提的是一種系統與設計層級的重構，而非單單只是程式碼層級的重構。
本書會以真實的遺留系統案例，來親自示範如何一步一步地重構，直到這個系統可以輕鬆應付未來的變更。同時，本書也強調許多觀念，例如不要做大佈局，因為『大佈局，你傷不起！』，本書強調只做今天的設計，解決今天的問題，完成今天的重構，讓明天見鬼去吧。因為你不是先知，你無法預測未來，做過多的設計是在浪費時間，要做的是『好的設計』而非『過多的設計』。什麼是『好的設計』，那就是明確地分層解耦，讓你的系統很可很輕鬆地面對將來未知的需求變更。
本書作者的程式與設計功力深厚，但撰寫這本書時，常常能夠站在基層工程師的角度出發，例如，對於大多數老闆而言，重構沒有立即效益，所以要如何說服老闆對遺留系統進行重構給予支持，才是重構得以實行的關鍵。只要你有『一點點』設計模式的底子，相信這本書會協助您解決許多正面臨的困難。
本書既稱之為『大話』重構，自然在文字用語上會有一些特色，以下舉幾個經典例句：

■ 「小步快跑」
■ 糟糕設計零容忍！
■ 小設計可以讓你獲得成功！
■ 自動化測試——想說愛你不容易
■ 系統重構最後的一里路——測試的困境。
■ 活在當下，設計今天的程式，讓明天的變化見鬼去吧！
■ 測試與重構形成了一個「雞生蛋，還是蛋生雞」的奇怪循環。
■ 合久必分，分久必合——類別的歸併
■ 領域才是軟體系統的「心」！
■ 開發糟糕程式碼是可恥的！
■ 大佈局你傷不起！
■ 「兩頂帽子」

這本書是一本關於重構，實踐經驗分享的書，至於這本書能夠帶給您多少的領悟，還得由您細細體會。

<章節目錄>

關於中文原創經典
關於本書封面
審校序
序
目錄

Part I 基礎篇

Chapter 1 重構：改變既有程式碼的一劑良藥
1.1 什麼是系統重構
1.2 在保險索上走鋼絲
1.3 大佈局與小步快跑
1.4 修改軟體的四種動機
1.5 一個真實的謊言

Chapter 2 重構方法工具箱
2.1 重構是一系列的等量變換—— 第一次HelloWorld 重構
2.2 盤點我們的重構工具箱—— 對HelloWorld 抽取類別和介面

Chapter 3 小步快跑的開發模式
3.1 大佈局你傷不起
3.2 小設計而不是大佈局
3.3 小步快跑是這樣玩的—— HelloWorld 重構完成

Chapter 4 保險索下的系統重構
4.1 你不能沒有保險索
4.2 自動化測試—— 想說愛你不容易
4.3 我們是這樣做自動化測試的—— JUnit 下的HelloWorldTest
4.4 採用Mock 技術完成測試

Part II 實踐篇

Chapter 5 第一步：從分解大函數開始
5.1 超級大函數—— 軟體退化的重災區
5.2 抽取方法的實踐
5.3 最常見的問題

Chapter 6 第二步：分拆大物件
6.1 大物件的演化過程
6.2 大物件的分拆過程——抽取類別與職責驅動設計
6.3 單一職責原則（SRP）與物件分拆
6.4 合久必分，分久必合——類別的歸併

Chapter 7 第三步：提高程式碼複用率
7.1 循序程式設計的煩惱
7.2 程式碼重複與DRY原則
7.3 提高程式碼複用的方法
7.4 重複程式碼的檢查工具

Chapter 8 第四步：發現程式可擴展點
8.1 開放—封閉原則與可擴展點設計
8.2 流程的擴展與放置鉤子—— 運用樣板模式增加可擴展點
8.3 剖面導向的可擴展設計
8.4 其他可擴展設計

Chapter 9 第五步：降低程式依賴度
9.1 介面、實作與工廠模式
9.2 外部介面與適配器模式——與外部系統解耦
9.3 繼承的氾濫與橋接模式
9.4 方法的解耦與策略模式
9.5 程序的解耦與命令模式
9.6 透明的功能擴展與設計——組合模式與裝飾者模式

Chapter 10 第六步：我們開始分層了
10.1 什麼才是我們需要的分層
10.2 怎樣才能擁抱需求的變化
10.3 貧血模型與充血模型
10.4 我們怎樣面對技術的變革

Chapter 11 一次完整的重構過程
11.1 第一步：分解大函數
11.2 第二步：分拆大物件
11.3 第三步：提高複用率
11.4 第四步：發現擴展點
11.5 第五步：降低依賴度
11.6 第六步：分層
11.7 第七步：領域驅動設計

Part III 進階篇

Chapter 12 什麼時候重構
12.1 重構是一種習慣
12.2 重構讓程式可讀
12.3 重構，才好複用
12.4 先重構，再擴展
12.5 變更任務緊急時，又該如何重構

Chapter 13 測試驅動開發
13.1 測試驅動開發（TDD）vs.後測試開發（TAD）
13.2 測試驅動開發與重構
13.3 遺留系統怎樣開展TDD

Chapter 14 全面的升級任務
14.1 計畫式設計vs.演進式設計
14.2 風險驅動設計
14.3 制定系統重構計畫

Chapter 15 我們怎樣擁抱變化
15.1 領域才是軟體系統的「心」—— 薪資軟體的三次設計演變
15.2 領域模型分析方法
15.3 原文分析法
15.4 領域驅動設計——使用領域模型與客戶一起設計
15.5 在遺留系統中的應用

Chapter 16 測試的困境
16.1 重構初期的困局
16.2 解耦與自動化測試
16.3 開發人員，還是測試人員
16.4 建立自動化測試體系

Chapter 17 系統重構的評價
17.1 評價軟體品質的指標
17.2 怎樣評價軟體品質呢

Appendix A 重構方法
A.1 重新組織函數
A.2 在物件間遷移
A.3 重新組織資料
A.4 簡化條件運算式
A.5 簡化方法呼叫
A.6 有關繼承的處理

本書結語 重構改變了世界
編輯的話

<作者簡介>

范鋼 軟體工程碩士，參與過數十件大型軟體研發專案，現任系統架構師，先後擔任過軟體工程師、需求分析師、專案經理、系統架構師等職務。長期關注軟體設計與品質的基礎理論研究與實務。並在Tid 軟體大會上針對《如何破解大型遺留系統技術改造的困局》發表演講。