倉廩實而知禮節，衣食足而知榮辱，這物質文明與精神文明的層級關係也一語道破了程式設計的層次級關係。程式設計也是如此，先滿足了功能需求，然後再對**進行重新整理、組織，達到易讀、易改、易擴充套件。這種對**重新整理的過程就叫**重構。
重構在不同的研發模式中的作用不盡相同。比如，在敏捷開發的研發模式中，重構的作用相當重要。敏捷開發運用迭代法進行產品開發，在迭代過程中分析、方案、**同時發生，並且弱化方案，強化**設計。在開發過程中，每次功能迭代程式設計師都根據現有**進行重構，盡量運用已有的**或函式，或者改造現有**使其滿足新功能需要。這樣使**實現高利用率，改善軟體的質量、效能，使其程式的設計模式和架構更趨合理，提高軟體的擴充套件性和維護性。
在過程式研發模式中，前期產品開發階段重構的作用不太明顯，而到後期產品維護階段重構則較為重要。因為過程式研發在**設計之前做了一系列工作——需求、方案，這些工作要求產品的功能和方案固定化，並且如果方案做的特別細的話，每個函式的實現方式，甚至**基本邏輯都已固定，到**實現階段只要把方案轉化成**就是。也就是說，在方案階段已經把重構的工作做的差不多。在後期維護過程或功能新增的過程中，則會參考之前的**。
我們目前用過程式研發模式，而我的研發水平處於實倉廩階段，在方案設計時只是注重功能實現，而沒有更多地考慮重構，後期維護也只是注重功能增加。久而久之，**將會架構模糊，函式重用率低，質量低下，功能增加困難。看了《重構-改善既有**的設計》之後，昨天我試著把事件模組做些簡單的重構，不到一天競重構掉了近200行**。由此可見在重構方面做的還很不夠。思想決定行動，意識決定高度，正如在實倉廩階段也要不僅僅為了吃個飽，要把產品當成一種藝術品來做，在細處打磨。現在已經有重構的意識，接下來會在新增功能、修補錯誤和複審**時盡量運用重構法則，對**進行整體把握，強化重構。砍柴不誤磨刀工。
說了這麼多，再說說什麼重構是什麼，什麼時候需要重構（來自《重構-改善既有**的設計》）。
重構：為保持**易讀，易修改，在不改變**外在的前提下，對**做出修改，以改進程式內部結構，提高其可理解性，降低修改成本。
要重構的**：可有可無的臨時變數，重複**，過長函式，函式功能過大，過長引數列，發散式變化，散彈式修改，資料泯團。
，「任何乙個傻瓜都能寫出計算機可以理解的**，惟有寫出人類容易理解的**，才是優秀的程式設計師」——作者如是說。
《重構》讀後感 長函式重構
的易讀性和效率是難以兼得的，作為乙個成長的第一步，我開始關注 的清晰程度。長函式往往是導致 晦澀難懂的罪魁禍首。解決的途徑就是對長函式進行分解，將其分解成為乙個乙個小函式。在書寫乙個函式時要秉承這樣乙個原則 函式名稱要與函式功能之間沒有語義差別。這樣寫出來的 即使不加備註，也是可以讓人比較容易看懂的...
《構建之法》讀後感 二
構建之法 這本書是很長時間以來讀到的第一本能夠吸引我的專業書。草草讀完整本書，我發現 構建之法 的作者文筆十分幽默風趣，書中把很多專業名詞或者專業知識用十分通俗的語言表達出來，甚至我們可以在書中看到很多對話形式的文字，通過這些對話，我們可以學到很多專業知識。相比於市面上很多其他專業書，這是唯一一本能...
《架構漫談》讀後感（二）
做好架構簡單來說就是找到需要解決的問題，如果把真正的問題找到，那麼問題就已經解決很大一部分了。講乙個比較好笑的現象，現在社會上的大多數人對程式設計師的印象都是高智商，低情商。很多人甚至編了很多日常生活中的笑話來調侃程式設計師的死板，不知道變通。當然 這些說話多少有點以偏概全。但是我們從中也能得到一些...