重構是一種對軟體進行修改的行為，但它並不改變軟體的功能特徵，而是通過讓軟體程式更清晰，更簡潔和更條理來改進軟體的質量。程式碼重構之於軟體，相當於結構修改之於散文。每次人們對如何對程式碼進行重構的討論就像是討論如何對一篇文學作品進行修訂一樣無休無止。所有人都知道應該根據專案的自身情況來對程式碼進行重構，而重構是無止境的。莫扎特從來不不對他的作品進行修訂，特羅洛普對自己作品修訂的恰到好處，大多數作家認為他們倆這樣做都是合適的，但他們的合適對於你我來說未必是合適的。
最常見的基本重構方法可以歸納為兩個方向。通過歸納方法將一個長的過程分解為小的可以重用的元件，和通過內聯(inline)方法來消除那些不夠份量的小方法。我們可以提煉方法來讓大量的子類共享相同的功能特徵，我們可以下放方法來讓只有用到這些功能的子類才知道它們的存在。重構就是爬山，通過一步一步的小的提高來逐漸的改進整體的質量，但在重構時，我們如何知道哪種方法是上山的正確道路？
關於程式碼地形學的這個問題公認的方法有兩種。去除有異味的程式碼和重構成模式。如果能做到這樣，當然是很好的。就像是糾正作文裡的一個語法錯誤或不恰當的比喻。如果我們可以找到這些四處隱藏的有異味的程式碼，將它們重寫成整潔的，條理的，結構化的形式，何樂而不為。但這些都是特殊情況。如果沒有明顯的模式來重構，或沒有很直接的方法來去除程式碼異味，那該怎麼辦呢？
這才是我們如今程式設計藝術的中心問題，而很少人討論這些。通常我們討論這些問題時都是羅列出更多更長的有異味的程式碼模式的清單，但這並不是解決問題的方法。程式碼異味應該是我們公認的不好的東西，而不是那些置之不理也無妨的事情。我們經常會說到老闆不給我們重構的機會，甚至程式碼有明顯的異味，老闆們認為這是浪費時間。並不是每個人都有懂軟體的老闆。我很吃驚為什麼只有很少的討論談到點子上。。也許我這篇文章才說到問題關鍵處。
我的觀點，當重構沒有現成的明顯的方向時，我們可以遵循下面的原則：
- 當屬性、方法或類存在任何的需要複用的意向時，歸納提煉它們。
- 不要低估小方法對程式碼整潔的作用。使用小方法能讓你節省很多筆墨。
- 能讓程式碼長度變短的提煉都應該去提煉，包括註釋。
- 用多形代替switch()——即使這樣做會使程式碼變長。
- 用封裝控制可見度。
- 消除依賴。
- 簡化構造方法——即使這樣做會使程式碼變複雜。
- 封裝或避免條件表示式。使用guard語句，避免使用
else語句。 - 使用常量代替魔幻數字。
- 不確定時，偏向使用組合而不是繼承。
- 不確定時，將計算操作移入到這些資料的所有者物件裡，或將資料移動到執行計算操作的物件裡(也就是迪米特法則(Law of Demeter))。
- 使用小物件，鬆耦合，避免大物件，高聚合。
- 不確定時，偏向使用遞迴而不是迴圈。
- 使用代理物件，模擬物件和輔助物件來隔離網路，資料庫，檔案和使用者介面。
- 不確定時，儘量在model裡新增程式碼，必要時才往controler新增程式碼。view裡新增的都應該是便捷功能和簡寫方法，但不要侷限於此。
- 偏向使用apply, each, mapcar，而不是loop.
- 儘量使用新技術。