《重構》 2 重構原則讀書筆記

（1）重構不只是整理**，而是一種更搞笑且受控的**整理技術。

（2）但必須對軟體【可受觀察之外部行為】只造成很小變化，或甚至不造成變化。與之形成對比的是【效能優化】。和重構一樣，效能優化通常不會改變元件的行為，只會改變其內部結構。但是兩者出發點不同：效能優化往往使**較難理解，但為了得到所需的效能你不得不那麼做。

（3）兩頂帽子：開發新功能、重構，會交替進行，但無論何時你都應該清楚自己戴的是哪一頂帽子

（1）如果沒有重構，程式的設計會逐漸腐敗變質。在完全理解整體設計之前，就貿然修改**，程式將逐漸失去自己的結構，程式設計師愈來愈難通過閱讀原始碼而理解原本設計。

（2）**數量減少並不會使系統執行更快，因為這對程式的執行軌跡幾乎沒有任何明顯影響。然而**數量減少將使未來可能的程式修改動作容易得多。

（3）如果你要修改一處功能，而修改多處**，**就會變得複雜而深奧，如果你能確定**將所有事物和行為都只表述一次，惟一一次，這正是優秀設計的根本。

（1）任何程式設計師，都會書寫大量的**，不可能所有**的實現都記得一清二楚，所以重構可以幫助我們更好地反映出我的理解，然後重新執行。

（1）重構能夠更有效地寫出強固穩健的**

（1）重構**並不能提高系統的執行速度，但是能提高軟體的可擴充套件性與開發速度。

（1）當重構的價值比維護**的價值高時，就值得重構

（2）新增新功能時是重構最好的時機，如果在前進過程中把**結構理清，就可以從中理解更多關於一開始的設計是出於什麼考慮的，另外一方面就是，**的設計無法幫助我輕鬆新增我所需要的特性，一旦完成重構，新特性的新增就會更快速、更流暢。

（3）修補錯誤時重構，由於**的結構不好，或者原來就存在臭蟲，往往出現修改**後沒有達到預想的後果，因為**被多次重複，重構能一目了然的發現臭蟲

（4）複審**，複審**最好乙個複審者搭配乙個原作者。

程式有兩面價值：【今天可以為你做什麼】--對於機器而言的

【明天可以為你做什麼】--對於人而言的

對於今天的工作，我了解得很充分，對於明天的工作，我了解得不夠充分。但如果我純粹只是為今天工作，明天我將完全無法工作

（1）由於軟體工程師對間接層如此醉心，你應該不會驚訝大多數重構都為程式引入了更多間接層。重構往往把大型物件拆成數個小型物件，把大型函式拆成數個小型函式。

但是，間接層是一柄雙刃劍。每次把乙個東西分成兩份，你就需要多管理乙個東西。如基於這個觀點，你會希望儘量減少間接層

（2）間接層的價值：允許邏輯共享、分開解釋【意圖】和【實現】、將變化加以隔離、將條件邏輯加以編碼

（1）重構之前，**必須起碼能夠在大部分情況下正常工作

（2）乙個折衷辦法就是：將【大塊頭軟體】重構為【封裝良好得小型元件】。然後你就可以逐一對元件做出【重構或重建】的決定

（3）你應該隨時準備重構，重構是開發中不斷進行的，出現新的功能時有需求的時候進行，並不能一次性設計，或過度開發而導致程式複雜而能達到重構目的，並不是為重構而重構

（4）如果專案已經非常接近最後的期限，你不應該再分心重構，因為已經沒有時間了。

（1）【事先設計】可以助我節省回頭工的高昂成本，但是要避免過分開發，因為如果最後發現所有這些靈活性都毫無必要，這才是最大的失敗。你知道，這其中肯定有些靈活性的確派不上用場。

（2）一旦需要重構，你總有足夠的信心去重構。是的，當下只管建造可執行的最簡化系統，至於靈活而複雜的設計，唔，多數時候你都不會需要它。

（1）關於重構，有乙個常被提出的問題：它對程式的效能將造成怎樣的影響？為了讓軟體易於理解，你常會做出一些使程式執行變慢的修改。這是個重要的問題

（2）任何修改如果是為了提高效能，通常會使程式難以維護，因而減緩開發速度。如果最終得到的軟體的確更快了，那麼這點損失尚有所值，可惜通常事與願違，因為效能改善一旦被分散到程式各角落，每次改善都只不過從【對程式行為的乙個狹隘視角】出發而已。

（3）重構和效能優化從某種意義上來說是兩個相反的方向，

重構--使**優化，易於維護，但可能會犧牲一點效能

效能優化--使**複雜，不易於維護，但可以提高執行速度

（4）如果你一視同仁地優化所有**，90%的優化工作都是白費勁兒，因為被你優化的**有許多難得被執行起來。你花時間做優化是為了讓程式執行更快，但如果因為缺乏對程式的清楚認識而花費時間，那些時間都是被浪費掉了。

（5）和重構一樣，你應該小幅度進行修改。沒走一步都需要編譯、測試、再次量測。如果沒能提高效能，就應該撤銷此次修改。

（6）短程看來，重構的確會使軟體變慢，但它使優化階段中的軟體效能調整更容易。最終我還是有賺頭

《重構》 2 重構原則 讀書筆記