譯本重構讀后感

時間：2021-06-10 12:06:57 讀后感我要投稿

譯本重構讀后感

　　網上對于這本書的評論很熱鬧，在讀《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測試構架。

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

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

【譯本重構讀后感】相關文章：