# 為什麼寫這本書
作者推崇的軟體設計方法，是以持續重構成為設計模式取代直接以設計模式進行開發。
直接以設計模式進行開發有什麼不好？可能產生的問題是：
- 過度設計
- 設計不足
# 過度設計（Over-Engineering）
- 什麼是過度設計：程式碼的彈性或複雜度超過需求
- 過度設計的影響：造成生產力低落
- 過度設計總在不知不覺中發生
# 設計模式萬靈丹（The Patterns Panacea）
學會設計模式以後，對所有問題都用設計模式來解決。
- 手裡拿著鎚子，看什麼都像釘子
- 產生的問題：殺機用牛刀
# 設計不足（Under-Engineering）
- 設計不足構成的因素
- 沒有時間或沒有撥出時間進行重構
- 沒有良好的軟體設計知識
- 太過盼望快速進入新功能至新的系統
- 被迫同時進行太多專案
# 測試驅動開發與持續重構
作者推崇的軟體開發方法。
步驟：
- 詢問（Ask）：透過撰寫測試程式來詢問系統問題
- 回答（Respond）：透過撰寫「可通過測試的程式碼」來回答問題
- 精鍊（Refine）：透過強化觀念、去除非必要事物以及釐清模糊地帶的方式來精鍊、強化你的答覆。
- 重複（Repeat）：透過詢問下一個問題來持續這樣的對話。
四字箴言：紅、綠、重構
- 紅：寫個測試，由於尚未撰寫讓測試通過的程式碼，此時測試失敗。
- 綠：寫出任何可以通過測試的程式碼。不必要求寫一個絕不重複、簡單、乾淨的設計。
- 重構：改善上述以通過測試的設計。
好處
- 讓程式錯誤數量維持在低水準
- 重構時不感到害怕
- 編寫出更簡單、更好的程式碼
- 寫程式沒有壓力
# 重構與設計模式
- 為什麼要重構成為設計模式：為了減少重複或移除重複、簡化複雜、讓程式碼更清楚傳達意圖
- 這本書的價值
- 《Design Patterns》只暗示 patterns 解決的主要問題，更多焦點放在 patterns 所做的事情上面，而非「協助讓你的設計問題與 patterns 所能解決的問題相契合」。
- 本書填補 patterns 和 refactoring 之間的空白
# 漸進式設計（Evolutionary Design）
- 了解「重構成為 patterns 或接近 patterns 的緣由」比「patterns 的最終結果或其實作過程中的細微差別」更有價值
- 研習「傑出設計的進化過程」比「傑出設計的本身」更有價值
# 重構清單
# 重構方向
