～-7-11 字數：1681
網上對於這本書的評論很熱鬧，在讀《java編程思想》感覺有點疲倦的時候，我拿起了這本書。這本書作者是martin fowler，而且封面上印著＂與《設計模式》齊名的經典巨著＂，＂《設計模式》作者為本書作序＂，＂超過70種行之有效的重構方法＂等宣傳語。對於這些宣傳語我第一個感覺是宣傳的噱頭，martin沒有必要通過本書與《設計模式》的比較顯示自己的身價。另外由於文中常常有交叉引用，可能侯捷／熊節採用頁頁對譯，顯得每頁留白很多。
開篇作者並沒有像常見的那樣為＂重構＂正名溯源，而是操刀剖析了一個出租影片程式的案例。原來的代碼能夠滿足當前需求的功能，但是面臨著眼前需要增加新功能列印html格式，日後可能變更影片分類的長遠需求。在變更前，作者對於最初的程式畫出了問號。然後按照每次謹慎地移動一小步，頻繁地測試的原則，對原來的代碼實施重構。小步挪動以後，擦亮了窗戶，對於程式的結構看得更遠了，繼續微調。終於在最後解決了該程式面臨的問題，增加了程式的靈活性，但是也使得代碼變得更加複雜了，減小了函式的功能粒度。似乎是微不足道的量變，產生了質變。代碼在沒有改頭換面的前提下進行了脫胎換骨。
第二章作者開始步入常規，解釋關於refactoring有關的what（重構是什麼），why（為什麼要重構），when（什麼時候進行重構），how （如何提出重溝）問題。作者也解釋了重構面臨的難題。我感興趣的是重構和設計，性能比較的兩節。通過對oop的學習，我逐漸理解和接受了項目逐步培養，成長的觀念。原來我一直按照瀑布式開發，在項目後期總出現一些當初設計想像不到的情況，開始我總歸結於自己經驗不足，需求分析做的不夠深入細緻。接觸到xp 和重構以後，心中有一種豁然開朗的感覺。但是我想重構與瀑布式並不是截然對立的，而是項目開發過程中兩個側面。在我所參與的動輒上百人參與，軟硬同吃的項目中完全採用xp是不可思議的，兩者必須結合使用。作者對於程式性能的問題的觀點也讓我耳目一新，他提出只有在需要的時候才著眼性能，而且通過測試而不是事前分析的方式尋找性能問題的瓶頸在那裡。
接著作者用22種代碼中的壞味道描繪了需要重構的種種徵兆。這一章和第6章一樣，我讀得很＂流＂，感覺內容很容易理解，但是讀完以後腦海中印象卻不深刻。尤其是具體的重構方法，有時候感覺作者挪動的步伐太小了，太謹慎了。也許像侯捷在序言中所說的，是日後計算機自動完成的步驟；也許是我看別人做事自己站著說話不腰疼，以後跌了大跟頭才能知道其中的真意吧。
uml class diagram 和 junit是順利進行重構的左右雙翼。在第1章中的那些unl類圖，我認為只是對代碼進行重構結果的解釋，並不是通過分析unl類圖發現需要重構的跡象。如果從項目整體或者多個類的關係入手進行重構的話，uml類圖可能能夠負擔行軍路線圖的重擔。（但是你為什麼要等到這時候才進行重構呢？）。而junit是進行頻繁測試的依仗，只有實現測試的自動化，才可能隨時的重構。作者用第4章一章的篇幅詳細介紹了測試的觀點，junit測試構架。