年前參加了軟體重構的培訓，就像老師所說，幾天的培訓不會有實質的變化，主要的目的是出發更深層次的思考和不斷的實踐，
1， duplicated code，重複**是最常見，醜陋的壞味道，有以下一些解決辦法
extract method －》pull up method
template method 這個準則最經常使用
substitute algorithm （這個準則實際中使用的還是比較少的，除非原有**實在是太混亂了）
extract class
2， long method， 專案中最長的方法將近2000行，
extraact method
replcae temp with query （個人認為，這個完全是為了**的可讀性，當專案龐大的時候，尤其重要）
introduce parameter object （將引數list封裝成class）
preserve whole object （傳遞整個物件，而不是物件中某幾個成員，可以達到減少引數個數的目的）
replacemethod with method object （臨時變數－》類的成員變數）
重要的切入點：尋找注釋，有注釋的地方通常可以提煉**
decompose conditional （把稍微複雜的條件表示式封裝成method）
3， long class， 超長的類，讓人望而生畏。尤其是長時間的閱讀**，會增加疲勞感
extract class
extract subclass
extract inte***ce（先確定客戶端如何使用它們，再做重構，會更有針對性）
如果是gui class， duplicate observed data， （比如事件模型）
4， long parameter list
replace parameter with method
preserve whole object
introduce paramter object
5， divergant change（發散式變化， 乙個class受多種變化影響）
extract class
6， shotgun surgery（霰彈式修改，一種變化引發多個class相應修改）
move method
move field
inline class
重構準則extract class，inline class看起來是相反的，說明乙個問題，重構有乙個度的問題，軟體設計也有乙個度的問題，這個度的把握需要case by case來看，沒有乙個定式準則，只能靠經驗來判斷，類之前的耦合度，成員變數之間，成員方法之間的關聯度與專案的複雜度有關係，並且要根據客戶端如何使用來判斷決定。
《重構》讀書筆記
再次看重構這本書，用了十幾分鐘，看完了原來斷斷續續用了差不多一周看完的第一章 沒有增加什麼新知識 僅對state stategy模式增加了點熟悉度 可見許久前學習第一章還是比較深入的，呵呵。還記得當時看得還是有點費力的。站的高度不同了，視角變化了，所以看得也快，看得也更精深。首先覺得第一章寫的真不賴...
重構 讀書筆記
1.重構的基本原則 新增新功能和重構是兩類工作。重構時，盡量不要新增新功能，除非發現了原來程式的錯誤。其實即使發現原來的錯誤，也應該把錯誤暫時記下來，待重構完成後，再修改原來的錯誤。重構就是不修改程式對外的表現形式，哪怕原來是錯誤的。2.重構時state模式的使用 當乙個物件中的某個屬性需要改變類屬...
重構讀書筆記
在乙個基礎系統上進行增量開發是比較常見的。增量開發的過程中，一方面會因為系統的初始框架有部分不適應新需求而變更，另一方面是維護開發人員更換，程式設計習慣及能力的差異，對系統的框架理解不一致，在進度的壓力下破壞了系統的框架。無論是哪一種，都有必要階段性的進行重構，以償還技術債務。技術債務不斷累加的後果...