一段我們的項目搞了一次重構，我簡單做了一個ppt，下面我們來一起分享下
代碼的壞味道
1、重複代碼（難維護）
•提取公共函數
2、函數過長（難理解）
•拆成若干函數
3、類過大（難理解）
•拆成若干類
4、參數多（難用）
•將參數封裝成結構或類
5、萬能類（改動頻繁）
•拆，將總是一起變化的東西放在一塊兒，合久必分
6、天女散花邏輯（需求變動改很多類）
•將各個修改點，集中起來，抽象成一個新類。
7、紅杏出牆的函數（使用了大量其他類的成員）
•將這個函數挪到那個類裡面。
8、數據團（常一起出現的一坨數據）
•他們那麼有基情，就在一起吧，給他們一個新的類。
9、冗餘類（如果不幹活了就幹掉他）
•提取公共函數
10、繼承過多（父類裡面方法很多，子類只用有限幾個）
•用代理替代繼承關係。
11、Switch驚悚現身（從本質上說，switch語句的問題在於重複）
•考慮用多態替換他
12、太多註釋
避免用註釋解釋代碼，而是說明代碼的目的，背景等。好代碼會說話。
重構是軟件發展的必然：
因為我們的軟件總是由簡單軟件向複雜軟件轉變；當軟件開始由簡單向複雜軟件轉變時我們就需要重構。
以上就是一個簡單的重構過程，重構是在日常工作不影響正常開發進度中進行的，這個需要根據我買項目的實際情況自己把握。
最後我在總結下：
1·持續偏糾和改進軟件設計
重構和設計是相輔相成的，它和設計彼此互補。有了重構，你仍然必須做預先的設計，但是不必是最優的設計，只需要一個合理的解決方案就夠了，如果沒有重構、程序設計會逐漸腐敗變質，愈來愈像斷線的風箏，脫韁的野馬無法控制。重構其實就是整理代碼，讓所有帶著發散傾向的代碼迴歸本位。
2·使代碼更易為人所理解
Martin Flower在《重構》中有一句經典的話：”任何一個傻瓜都能寫出計算機可以理解的程序，只有寫出人類容易理解的程序才是優秀的程序員。”對此，筆者感觸很深，有些程序員總是能夠快速編寫出可運行的代碼，但代碼中晦澀的命名使人暈眩得需要緊握坐椅扶手，試想一個新兵到來接手這樣的代碼他會不會想當逃兵呢？
軟件的生命週期往往需要多批程序員來維護，我們往往忽略了這些後來人。為了使代碼容易被他人理解，需要在實現軟件功能時做許多額外的事件，如清晰的排版佈局，簡明扼要的註釋，其中命名也是一個重要的方面。一個很好的辦法就是採用暗喻命名，即以對象實現的功能的依據，用形象化或擬人化的手法進行命名，一個很好的態度就是將每個代碼元素像新生兒一樣命名，也許筆者有點命名偏執狂的傾向，如能榮此雅號，將深以此為幸。
對於那些讓人充滿迷茫感甚至誤導性的命名，需要果決地、大刀闊斧地整容，永遠不要手下留情！
3·幫助發現隱藏的代碼缺陷
孔子說過：溫故而知新。重構代碼時逼迫你加深理解原先所寫的代碼。筆者常有寫下程序後，卻發生對自己的程序邏輯不甚理解的情景，曾為此驚悚過，後來發現這種症狀居然是許多程序員常患的”感冒”當你也發生這樣的情形時，通過重構代碼可以加深對原設計的理解，發現其中的問題和隱患，構建出更好的代碼。
4·從長遠來看，有助於提高編程效率
當你發現解決一個問題變得異常複雜時，往往不是問題本身造成的，而是你用錯了方法，拙劣的設計往往導致臃腫的編碼。
改善設計、提高可讀性、減少缺陷都是為了穩住陣腳。良好的設計是成功的一半，停下來通過重構改進設計，或許會在當前減緩速度，但它帶來的後發優勢卻是不可低估的
閱讀更多 程序猿的內心獨白 的文章
