淺談重構
前篇 Clean Code 簡單原則 中，談到寫出好的程式碼有兩個方法：一個是一開始就寫出乾淨的程式碼，但在對整個程式架構都不明瞭的情況下，就得寫出完美的程式碼非常困難；另一個則是靠重構程式碼，透過一次次等價交換小塊程式碼，讓其慢慢變得更乾淨。 重構是什麼？ 重構就是一種在不改變程式外在表現的前提下，將其程式碼變得更容易閱讀，且更容易修改。 通常聽到重構，可能會聯想到大興土木的變革，其實不然。重構是一種寫程式的小習慣，是每次動手寫新程式前都會做的事情，有點像是打掃房間一樣，每次進房看到有髒亂的地方就順手整理一下，維持房間的乾淨整齊，而不是等到東西都堆滿地，想要放一張新的桌子都沒地方可以擺。 另外，重構可以幫助我們慢慢形塑整個系統，讓軟體一直貼近實際需求。以往瀑布式開發一開始精心規劃的架構，拆成一塊一塊後分批完成，最後統合起來形成整個系統。但需求一直在改變，從規劃到釋出軟體經過了一年以上，到時市場趨勢已經不是當初規劃的那個樣子，會造成極大的風險。  隨著敏捷開發的出現，人們開始縮短開發週期，加快取得使用者的回饋，以利調整方向，但這會造成程式碼必須頻繁的修改。  改動就會有風險，在開發的過程中需要利用**兩頂帽子**的設計方式：「重構」與「添加新功能」。重構確保所有功能不被更動的前提下，利用每次的等價交換，重新思考如何將程式碼分拆成小塊容易維護的樣子，並將區塊間的相依性降低，之後再來添加新功能。 講了這麼多，重構到底要怎麼進行呢？先有程式碼好壞的概念後，找到程式碼中不好的地方，用查表的方式替換成新的形式，代換完後測試一下程式，觀察結果是否與更改前一致，若一致就可以再尋找其他地方進行重構或添加新功能。 在 重構─改善既有程式的設計 這本書提到一些程式碼的壞氣味： Duplicated code 重複的程式碼 Long method 過長函式 Large class 過大類別 Long parameter list 過長參數列 Divergent change 發散式變化 Shotgun surgery 散彈式修改 Feature envy 依戀情結 Data clump 資料泥團 Primitive Obsession 基本型別偏執 Switch Statements 可怕的 Switch Parallel inheritance hierarchies 平行繼承體系 Lazy class 冗員類別 Speculative generality 夸夸其談未來性 Temporary field 迷惑的佔時欄位 Message chains 過度耦合訊息鏈 Middle man 中間轉手人 Inappropriate intimacy 狎暱關係 Alternative class with different interfaces 異曲同工的類別 Incomplete library class 不完善的程式庫類別 Refused bequest 被拒絕的遺贈 Comments 過多的註釋 在大話重構這本書中提供了一些較簡單的方向：...