最近閱讀
Martin Flower
的《重構》，對自己有許多啟發，以前認為一些正確的觀點現在看來也不那么正確了；同時發現對重構的理解只有在閱讀了書之后更加徹底；在閱讀《重構》之后我對其中幾點有點感觸：
?
1.
在沒有具體閱讀《重構》之前，我認為重構就是將代碼變的容易理解，容易維護，但在閱讀了《重構》之后才發現重構不僅可以利用到重新構造已有的代碼，也可以幫助我們在閱讀代碼的過程中增加我們的對代碼理解的速度。其實我想每個學習編寫代碼的同行都在學習的過程中閱讀過別人的代碼，然后還有可能將別人的代碼拿到計算機上編譯運行來查看結果表現。實際上我認為這在某種意義上屬于重構，只是重構的粒度有多大，或許你修改別人的代碼一部分來查看修改的結果，從而幫助自己掌握軟件中的更多特性，或者說讓自己修改的代碼表現出原來的功能。
Martin Flower
說的就是如此，我們如果沒有得到別人完整的文檔，那我們怎么樣才能理解別人的代碼來，好的辦法就是我們一邊閱讀別人的代碼，一邊部分部分的修改他人的代碼，然后測試每次修改的結果與以前的結果是否一樣，如果一樣，那么你的重構代碼是正確，那么你肯定能夠理解你自己寫的代碼吧（自己都不理解自己的代碼就不要干了）；別人的代碼就這樣在我們一部分一部分重構當中被我們理解了。
?
2.
以前我們寫代碼的時候喜歡設計，設計的我們認為很詳細了，然后開始將所有的功能模塊都寫完，接著再調試，在調試的過程中我們可能花費比寫代碼長的多的時間。是的，因為你在運行一個復雜的東西，當然不容易搞定了。
Martin Flower
認為我們調試的時間可以不用那么長，原因是我們不能在寫完了一個復雜系統的時候再調試，我們可以先建立一個好的測試用例，在寫這個測試用例的過程中我們更能對整個系統了解，也能夠幫助我們寫代碼；然后我們一點點的寫，寫一部分測試一下，保證每次新寫的代碼都能正確運行，從而當代碼寫完了，系統調試也完畢了。這樣的情況下可以認為我們沒有在調試上花時間，我們把時間花在測試和編寫代碼上了。
?
3.
以前認為代碼當中注釋越多越好。
Martin Flower
又一次給我們教訓說，寫注釋是因為你的代碼已經不能告訴代碼閱讀者他的真實意思了。是的，好的代碼可以通過很多方式表達其自身的含義，例如變量的名稱，函數的名稱等；就如一個比較條件判斷來說吧，我們有必要的情況下將這個即使很短的條件抽取一個方法，然后用方法名稱來告訴讀者判斷的真實意義，如果這里直接使用條件判斷就要讓讀者迷惑半天，當然這里的前提是給變量和函數起一個合適的名字，這是考驗程序員真功夫的地方了。另外，這里說的不是說寫注釋不好，如我的目的是如果代碼可以描述意義了，注釋就不需要寫了，這樣就讓你省了一件事情：保證代碼和注釋的同步，這不是更好。
?
4.
在之前我也認為重構會花費很大代碼，因為我們要理解代碼，重新編寫；但為了修改
BUG
，
Martin Flower
告訴我們重構是最快的。也許不相信，我也不相信，但他說的有道理，容易修改的
BUG
，當然早就被修改了，那么剩下的
BUG
就很難找了，主要因為代碼中的邏輯不清楚，重構可以改變這種情況，讓我們的代碼有條有理，那么當然
BUG
就無處藏身了。
?
5.
勇于接受變化。以前認為用戶頻繁的變化需求是不可理喻，實際上是我們自己不可理喻，他們花錢當然需要能提供高質量的服務；而
Martin Flower
認為不用怕改變，我們有重構工具，重構可以讓我們代碼任何時候都是清楚的，容易修改的，那么變化是件快樂的事情不再象以前那樣艱難了。
?
6.
重構與性能不是對立的。重構讓代碼容易理解，而性能讓代碼變的難以理解，不過我們在開始的時候應該考慮怎么樣讓代碼容易理解和維護，這樣我們可以在后面適當的時候對代碼的某部分進行輕松的性能改進工作。本人做性能改進工作有段時間了，想從龐大的雜亂無章的、不熟悉的代碼中找出性能的
bottleneck
的確不是一件容易的事情，我需要的是理解代碼，理解流程，那么如果一個結構很好的代碼對于我來說就好對付多了。因此他們不是對立的，性能以重構為基礎的。
?
其實通過重構，最主要的目的是讓我們的代碼更清晰，更輕巧，更容易被維護，那么也就是我們有良好的代碼，于是我們還懼怕什么，什么都可以輕松搞定。同樣《重構》認為代碼隨時都是清晰的、輕巧的，一般你的代碼不再具有以上特點，那么我們就需要使用重構了。
本人說不當之處請大家指教。