1.何謂重構？

答：

A.重構（名詞意義）：對軟體內部結構的調整，目的是在不改變軟體可觀察行為的前提下，提高其理解性，降低其修改成本；

B.重構（動詞意義）：使用一系列重構手法，在不改變軟體可觀察行為的前提下，調整其結構；

總結：為了更容易理解和修改軟體，在不改變軟體功能的前提下，調整軟體結構；

重構的兩種思維：在軟體開發的過程中，編碼和重構經常會交叉，因為二者是兩種不同思維方式，為避免產生思維混亂，最好將二者獨立開來：同一時間只做同一件事，要麼程式設計，不做重構；要麼重構，不做程式設計；

評：程式設計考慮的是實現功能，為此常常可能犧牲結構、效能、擴充套件性，著眼的是區域性等，這都是難免的；重構考慮的是重新梳理軟體的功能之間的邏輯和功能內部的實現，著重的是系統，所以更多的是考慮理解性、擴充套件性、穩定性等；如果二者同時進行的話，可能就會產生考慮過多，導致無法編碼或編碼艱難；本質上，編碼和重構是存在矛盾的，結合我以往的經歷來看，同時做兩件相互衝突的事，就會喪失思考力，因為你考慮的東西太多，結果反而不知如何是好了！

總評：把軟體比作人體，重構就是鍛鍊身體，可以排除體內的負能量（垃圾、毒素等），也可以提升自身的身體素質，增加器官的活性，提升身體的抵抗力； 你可以去健身房，也可以抽個業餘時間；鍛鍊的目的一般來說有兩個：1.改變個人的精神狀態，使得身體處於積極狀態；2.為了追求身體之美，像古希臘人一樣為了追求身體之美而鍛鍊；

２.為何重構？

A.改進軟體設計：軟體的設計隨著時間的流逝，會逐漸的腐敗。當程式設計師修改和新增功能的時候，著重的是功能的實現。所以無法統攬全域性，從系統的角度來考慮修改或新增的模組對整體的影響；所以我們需要重構，來幫助我們不斷矯正軟體，使之穩定執行；

評：猶如人體之五臟六腑，各官其能，經由血管脈絡連貫全身，使人能正常生存並思考；人體的結構是進化的結果，進化總是傾向完美性或適合性的；計算機就是軟體的生活環境，如果軟體的結構很糟糕，那麼軟體也是執行的很不開心的。重構就相當於使得軟體的結構更加符合計算機的要求；歸根到底，在我看來，計算機的結構本身就是人利用思維創造的合理性的實體，也是人的思維的體現；軟體也是思維的產品；我們要做的就是讓一件產品執行到另外一件產品中；

B.讓軟體更易理解：軟體的執行是在計算機中進行的，但是軟體的開發往往是多人開發整合的；所以我們在追求計算機的理解的同時，也要讓別人理解。後者往往要比前者花費的時間更長，更影響軟體的執行；

評：“幸福家庭家家相似，不幸的家庭各各不同”，合理性對於所有人來說是相同的；所以合理性也是衡量軟體質量的一個標準（自我理解），所以，如果別的程式設計師看不懂我們的軟體的時候，在懷疑他人的能裡的同時也應該考慮自己的設計是否真的合理；就像1+1 = 2，你可以不喜歡，但是隻要你能理解對軟體來說就是成功的；

C.提高程式設計速度：對系統的理解時間要大於程式設計時間，如果對整個系統胸有成竹，接下來只是寫程式碼的功夫了；

評：語言都是一種世界觀，java的面向物件、C的面向過程本質上都是一種對世界的理解；慢慢的就會發現，所謂程式只是用來實現功能，真正困難的還是人對事物的理解和認識；就像王國維的人生三境“看山是山，看水是水”、“看山不是山，看水不是水”、看山還是山，看水還是水“。重構考究的就是程式設計師的思維境界，看水還是看水全看個人能力；境界高，看待事物的方式不同，解決起來也是容易的很；境界低，只能不斷摸索，最後還是執於一隅；

D.重構找到bug：重構就是讓軟體系統重歸合理性之旅，必須梳理清楚軟體系統的邏輯，在復歸合理性的過程中，我們會逐漸的發現不合理之處（bug）。

總評：為何重構猶如問人為何鍛鍊身體一樣。改進軟體設計和重構找到bug，相當於人通過鍛鍊修復身體的損傷，保證了人的正常功能；讓軟體更易理解和提高程式設計速度就相當於改善個人的狀態，使得充滿激情和正能量；我的感受是一般運動後都會很放鬆，也更健談，做事的效率也會提升很多；

3.何時重構？

答：軟體程式無非是增刪改查，新增和去除功能的時候要重構，一方面是為了下次能更好的理解增加的功能模組，其次也是為了在開發的過程中逐漸的把程式碼結構理清，便於接下來的開發；修改功能時要重構，除錯過程中重構，讓程式碼更具可讀性，設想如果程式出錯，而我又無法準確定位原因的時候，充分反應了程式碼不夠清晰，無法鎖定異常所在；查即程式碼複查，程式碼複查類似於”結對程式設計“，讓別人理解你的程式，一方面突破自己的固有思維模式，同時也是判斷軟體的可讀性的一種方式；

4.何時不該重構？

答：

A.現有程式碼過於混亂，重構的成本大於重寫

B.程式碼在大部分情況下無法正常執行，稍作改動，就報很多錯誤，無法穩定運作；

C.專案臨近交付的時候；

5.重構的難題

A.資料庫：資料庫重構的難題有二：1.商用軟體的資料庫和業務關聯；2.資料的遷移；

B.修改介面：面向物件的封裝性使得程式設計師可以將功能實現和介面獨立開來，介面一旦釋出，就很難修改。所以如果功能擴充套件而舊介面無法滿足需求時，一個不壞的方法就是在舊介面中呼叫新的介面；其次，務必注意，介面釋出之先，一定要修改程式碼所有權政策；

C.難以通過重構手法完成的設計改動：有些專案過大，通過重構完全無法修改程式的設計

6.設計與重構

A.只有設計：結合我自身的專案經歷來看，由於初始使用者需求不是太明確，專案又略顯複雜。所以在開發之初總是想著考慮各種情況，儘量的讓軟體設計保持靈活；但是最後卻發現，在開發的過程中總是會遇到各種問題，這個時候只能是修改設計，開發到最後設計也面目全非了，開發過程中也很累；

B.只有重構：只有重構而不考慮開前的設計倒也可以，一個問題是如果不能熟練的掌握重構，要想在開發過程中很好的重構程式幾乎是不可能的；畢竟設計更著重與系統的流程和架構，受業務影響，重構更關注的是功能模組的實現邏輯和模組之間的關係，更偏重技術角度；

C.設計+重構：這種方式會好很多，一方面可以簡化設計，同時簡化的設計又可以很好的指導開發，在開發的過程中遇到問題也可以通過重構靈活的修改設計；也就是說我們掌握重構後有足夠的信心應對需求的變化。

7.重構與效能

  重構不一定提升軟體效能，但可以使效能提升更容易；效能提升一般有三種方式：

  A.時間預演算法：預先定義軟體各功能模組的時間成本，嚴格控制，從而提升系統執行時間；對於一般軟體來說，無需這種要求；

  B.持續關注法：程式設計師在做任何修改時，必須保證程式的高效能；一般很難實現，因為任何一次的修改如果是為了效能提升的話，通常都會使程式難以維護；如果以此換來程        序的效能提升倒也值得，但是大部分情況下並非如此；效能改善往往著於一角，區域性的效能提升了，但是整體的效能卻是無法保證；不過就我開發的經歷來說，部分效能的        提  升在很大程度上會提升系統性能，當然前提是軟體編碼很糟糕，有很大的優化空間；

  C.根據二八原則，影響程式80%效能的往往是20%的程式碼；所以初始編碼的時候無需耗費過多精力於重構，待編碼完成，就集中精力測試，找到影響效能的20%程式碼，然後採用持續關注法和時間預演算法（我認為兩種方式可以交叉使用），集中優化；

8.重構源於何處？

你猜！