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