《重構》讀後感

～-7-11　字數：1681

網上對於這本書的評論很熱鬧，在讀《java程式設計思想》感覺有點疲倦的時候，我拿起了這本書。這本書作者是martinfowler，而且封面上印著＂與《設計模式》齊名的經典鉅著＂，＂《設計模式》作者為本書作序＂，＂超過70種行之有效的重構方法＂等宣傳語。對於這些宣傳語我第一個感覺是宣傳的噱頭，martin沒有必要通過本書與《設計模式》的比較顯示自己的身價。另外由於文中常常有交叉引用，可能侯捷／熊節採用頁頁對譯，顯得每頁留白很多。

開篇作者並沒有像常見的那樣為＂重構＂正名溯源，而是操刀剖析了一個出租影片程式的案例。原來的程式碼能夠滿足當前需求的功能，但是面臨著眼前需要增加新功能列印html格式，日後可能變更影片分類的長遠需求。在變更前，作者對於最初的程式畫出了問號。然後按照每次謹慎地移動一小步，頻繁地測試的原則，對原來的程式碼實施重構。小步挪動以後，擦亮了窗戶，對於程式的結構看得更遠了，繼續微調。終於在最後解決了該程式面臨的問題，增加了程式的靈活性，但是也使得程式碼變得更加複雜了，減小了函式的功能粒度。似乎是微不足道的量變，產生了質變。程式碼在沒有改頭換面的前提下進行了脫胎換骨。

第二章作者開始步入常規，解釋關於refactoring有關的what（重構是什麼），why（為什麼要重構），when（什麼時候進行重構），how（如何提出重溝）問題。作者也解釋了重構面臨的難題。我感興趣的是重構和設計，效能比較的兩節。通過對oop的學習，我逐漸理解和接受了專案逐步培養，成長的觀念。原來我一直按照瀑布式開發，在專案後期總出現一些當初設計想象不到的情況，開始我總歸結於自己經驗不足，需求分析做的不夠深入細緻。接觸到xp和重構以後，心中有一種豁然開朗的感覺。但是我想重構與瀑布式並不是截然對立的，而是專案開發過程中兩個側面。在我所參與的動輒上百人蔘與，軟硬同吃的專案中完全採用xp是不可思議的，兩者必須結合使用。作者對於程式效能的問題的觀點也讓我耳目一新，他提出只有在需要的時候才著眼效能，而且通過測試而不是事前分析的方式尋找效能問題的瓶頸在那裡。

接著作者用22種程式碼中的壞味道描繪了需要重構的種種徵兆。這一章和第6章一樣，我讀得很＂流＂，感覺內容很容易理解，但是讀完以後腦海中印象卻不深刻。尤其是具體的重構方法，有時候感覺作者挪動的步伐太小了，太謹慎了。也許像侯捷在序言中所說的，是日後計算機自動完成的步驟；也許是我看別人做事自己站著說話不腰疼，以後跌了大跟頭才能知道其中的真意吧。

umlclassdiagram和junit是順利進行重構的左右雙翼。在第1章中的那些unl類圖，我認為只是對程式碼進行重構結果的解釋，並不是通過分析unl類圖發現需要重構的跡象。如果從專案整體或者多個類的關係入手進行重構的話，uml類圖可能能夠負擔行軍路線圖的重擔。（但是你為什麼要等到這時候才進行重構呢？）。而junit是進行頻繁測試的依仗，只有實現測試的自動化，才可能隨時的重構。作者用第4章一章的篇幅詳細介紹了測試的觀點，junit測試構架。

從名為“重新組織你的函式”的第6章開始，作者詳細介紹了每一種重構方法。對於每種方法，按照名稱(name)、概要(summary)、動機（motivation）、做法(mechanics)、範例(examples)的格式進行。這麼多模式，很難記憶完全，也沒有必要。我想如果理解了重構的概念和原理，具體的模式可以像字典一樣平時多翻翻，多琢磨。具體做的時候沒有必要非要搞清楚自己使用的是哪一種模式，然後嚴格按照書上的步驟照貓畫虎。無招勝有招，把重構融入到自己平時的程式設計過程中才是真正掌握了。

這本書翻譯得很流暢，我在不知不覺中被文中生動自然的語言帶到桃源深處，領略別樣風景。至於網友常常爭論的翻譯，用詞等問題，我並不在意，也絲毫沒有構成我閱讀的障礙。我關注的是原理，技術本身，而不是某個詞的譯法、用法，因為我知道“個別程式碼的優化調整，對整個系統毫無意義”。