我們聽過或許沒有聽過那些術語和概念，多少明白或完全不明白的技術和方法，知道卻沒用過或完全不知道的工具和軟體，這些之前各玩各的的獨立散碎，在這本書中被榫卯成一個強韌的整體。你會明瞭它們中每一個的作用，應被安插到的位置，並見識它們各就各位時所發揮出的能量。頭腦從未有過的清醒，我們理解了以前所不理解的，今天這篇博文，小編就來簡單的介紹一下大話重構的故事，為什麼小編會有一種大話西遊的感覺呢？`(*∩_∩*)′

       重構，是一把雙刃劍，開發人員不要輕易使用。舉個例子來說，你現在正在從事某個行業的工作，但有人告訴你另外一個行業賺錢多而且快，於是你就很糾結，到底要不要改行呢？不改行吧，錢掙得少；改行吧，自己又是新手，對那個行業又不熟悉。這種心理狀態其實就是開發人員對於重構的態度，可以用“進退維谷”來形容。 

      由於原程式結構不能滿足使用者的新需求、原程式有漏洞（bug）、原程式執行效率低下，效能不足以滿足使用者要求。所以要而且必須要進行重構。但是重構不能隨隨便便的進行重構，重構是要按照一定的原則來進行的，重構的原則：小步快跑（一次一小步的修改模式，每次修改一點點進行一個測試，再修改一點點再測試）；兩頂帽子（一頂是隻重構原始碼而不增加新功能，一頂是增加新功能以實現新需求）。

        一個軟體總是為解決某種特定的需求而產生，時代在發展，客戶的業務也在發生變化。有的需求相對穩定一些，有的需求變化的比較劇烈，還有的需求已經消失了，或者轉化成了別的需求。在這種情況下，軟體必須相應的改變。考慮到成本和時間等因素，當然不是所有的需求變化都要在軟體系統中實現。但是總的說來，軟體要適應需求的變化，以保持自己的生命力。       這就產生了一種糟糕的現象：軟體產品最初製造出來，是經過精心的設計，具有良好架構的。但是隨著時間的發展、需求的變化，必須不斷的修改原有的功能、追加新的功能，還免不了有一些缺陷需要修改。為了實現變更，不可避免的要違反最初的設計構架。經過一段時間以後，軟體的架構就千瘡百孔了。bug越來越多，越來越難維護，新的需求越來越難實現，軟體的架構對新的需求漸漸的失去支援能力，而是成為一種制約。最後新需求的開發成本會超過開發一個新的軟體的成本，這就是這個軟體系統的生命走到盡頭的時候。重構就能夠最大限度的避免這樣一種現象。系統發展到一定階段後，使用重構的方式，不改變系統的外部功能，只對內部的結構進行重新的整理。通過重構，不斷的調整系統的結構，使系統對於需求的變更始終具有較強的適應能力。重構可以降低專案的藕合度，使專案更加模組化，有利於專案的開發效率和後期的維護。讓專案主框架突出鮮明，給人一種思路清晰，一目瞭然的感覺，其實重構是對框架的一種維護。

       總的數來，對於程式來說，重構就相當於做一次大的手術，因此一定要認真對待。貫穿整個重構過程的是不斷地測試、測試、再測試。我們需要不斷地實踐才能夠對整個重構的流程得心應手。因此從“小步快跑”和“兩頂帽子”兩個重要的重構思想，再到系統重構六步驟：分解大函式、拆分大物件、提高程式碼複用率、發現擴充套件點、減低依賴度、分層，這些都是重構很重要的部分。在重構時要放棄大布局，採用小設計。這種說法很有意思，感覺有點不符合我們平時正常的思維習慣，錯誤發現得越早就越利於修正錯誤。如果佈局太大，錯誤被發現的可能會越遲，這樣修正起來也更加複雜。重構時如果步子走的太大，其實花費在設計上面的時間也越多，開發週期也越長。因為考慮的太多，會導致各種各樣的問題出現。 所以採用小步快跑的方式來進行重構，由於每次只關注其中的一部分功能，這樣不論從設計還是開發，測試的角度來說，都是非常有利的。因為我們採用的是"小步快跑"的方式去重構，即使中間我們犯了一些錯誤，還是非常容易地被發現，修正。這極大的減少了我們的工作量。

       在緊急變更任務中，時間就是金錢，我們要用最省時省力的方法解決問題，這裡的差別就是怎樣去重構？——做完整的設計， 但只做重構中最緊急的部分。

      第七步：領域驅動設計：按照職責原則對系統進行領域劃分形成領域模型。原程式結構與現程式結構大相徑庭，並不是拋棄原有系統結構，只是通過”小步快跑”一點一點的演變而來，再次保證程式碼的質量水平和閱讀、維護、變更。這就是重構的完整過程。

      小編寄語：該博文，小編簡單的介紹《大話重構》，博文分別從，整體把控整本書、何為重構、為什麼要重構、什麼時候重構、如何重構五個方面進行歸納總結，重構的重點，不在於如何重構，而在於重構釋義過程的美學顯現。