在乙個基礎系統上進行增量開發是比較常見的。增量開發的過程中，一方面會因為系統的初始框架有部分不適應新需求而變更，另一方面是維護開發人員更換，程式設計習慣及能力的差異，對系統的框架理解不一致，在進度的壓力下破壞了系統的框架。 無論是哪一種，都有必要階段性的進行重構，以償還技術債務。技術債務不斷累加的後果，是修改越來越複雜，當適當的修改點越來越難找，犯錯的機會越來越大。
讀《大話設計模式》時，就一直有幾個問題：
1. 」系統框架修改點在哪？「 ，乙個好的框架，在修改點的擴散會做的比較好。
2. 」邏輯放在**？「，這是乙個非常重要的問題，書上提到的」功能帽子「，是乙個不錯的說法。
3. 」系統的體積（**量）一直在膨脹， 什麼情況下，能將一些過時的功能去除？「。前段時間，看小公尺的乙個介紹，說通過與客戶的互動，對功能受歡迎度排序，可以達到去除不實用的功能。 只有對使用者需求，深度分析，才能從源頭上重構需求。
重構，必須要有乙個對應的功能測試系統來保障，對於乙個複雜的大系統而言，功能流程的覆蓋面有點困難。
書中第一章展示了乙個重構的例子。例子中，用到了如下幾種重構方法
1. 拆解功能邏輯， 如將switch邏輯，拆成乙個單獨函式。
2. 對臨時變數，根據唯讀與修改進行分類，決定拆分的函式是傳參還是返回值。書中的觀點認為臨時變數會增大函式的規模。通過函式的封裝可以減少臨時變數的使用。
3. 由於函式中會對資料交叉使用， 這裡提到乙個很有用的方法：函式方法移動。 也就是說，將這些函式，移動到對應的資料類中，作為資料類的方法。這實際上是在修復被破壞的類。
4. 使用多型，繼承，抽象介面
5. 使用設計模式--策略，重新優化結構。實現上這就是類的設計重構。
《重構》讀書筆記
再次看重構這本書，用了十幾分鐘，看完了原來斷斷續續用了差不多一周看完的第一章 沒有增加什麼新知識 僅對state stategy模式增加了點熟悉度 可見許久前學習第一章還是比較深入的，呵呵。還記得當時看得還是有點費力的。站的高度不同了，視角變化了，所以看得也快，看得也更精深。首先覺得第一章寫的真不賴...
重構讀書筆記
年前參加了軟體重構的培訓，就像老師所說，幾天的培訓不會有實質的變化，主要的目的是出發更深層次的思考和不斷的實踐，1，duplicated code，重複 是最常見，醜陋的壞味道，有以下一些解決辦法 extract method pull up method template method 這個準則最...
重構 讀書筆記
1.重構的基本原則 新增新功能和重構是兩類工作。重構時，盡量不要新增新功能，除非發現了原來程式的錯誤。其實即使發現原來的錯誤，也應該把錯誤暫時記下來，待重構完成後，再修改原來的錯誤。重構就是不修改程式對外的表現形式，哪怕原來是錯誤的。2.重構時state模式的使用 當乙個物件中的某個屬性需要改變類屬...