大道化簡，重構的藝術

這個題目貌似很大，有成為標題黨人的嫌疑。其實我想說的是一些小事，就是我小時候經常去小渠裡抓魚。而抓魚的方式也很簡單，就是拿磚塊，泥巴把小渠的兩頭堵起來，然後把中間的水舀出去。

 

軟體為什麼要重構？那是因為你感覺不夠好。之所以感覺不夠好，原因可能會很多。我想，最嚴重的一個可能就是設計混亂。設計混亂牽扯的方面很多，有依賴上的，有調用上的。也有根本實現不了目的，或者很難擴充。有很多人重構時候乾脆就是把代碼重寫一遍，這種方式固然是好，但是成本太高。有時候無法接受重新梳理一遍代碼的工作周期。

 

如何漸進地進行重構不得不擺在我們面前，而我沒有珍惜，等............

 

對於依賴關係錯誤的重構是最為複雜的。這個複雜表現在必須重新理順依賴關係，然後得出解決的方案。而代碼調用讓人頭疼的地方，我想主要在於，沒有重用和過度重用兩種。擴充上的問題需要重新梳理商務規則，才能制定方案。

 

毛病很多，頭疼醫頭，腳疼醫腳，還真是麻煩。其實最根本的方法還在於學會養生，修鍊內功。但路總要一條一條走，飯要一口一口吃啊。遇到這麼多複雜的問題，還需要化繁為簡。這裡的化繁為簡在我看來和我小時候抓魚差不多，需要能夠對大量的工作進行截斷，一個階段一個階段地進行重構。這樣才能達成漸進的重構目的。

 

如何進行工作量的切斷，方法很多，但是有個根本的思想在於理清依賴。比如，類B調用了類A，那麼B就對A產生了依賴。現在需要對A進行調整，那麼就有很大可能對B的正常運行產生影響。如何能隔離B和A，這就需要給A定義規範。這也就是對A進行抽象，提煉出介面IA，那麼不管你A怎麼變，你符合IA介面的話，就可以給B使用。IA就像我抓魚時候築的那條小壩，雖然很小，卻很能解決問題。

 

為什麼這樣可以解決問題？這就在於，任何一個消費者不會需要知道生產者的一切東西。那麼只要把消費者需要的東西拿到就可以。MVC，MVP，三層架構都是大壩，是水渠的兩邊。而大半架構都是進行水平的劃分，垂直的劃分一般是以業務來劃分。所以，如果軟體已經實現了水平的劃分，重構起來要輕鬆很多。那樣只需要對業務的垂直劃分進行逐步的改造。而如果水平劃分沒有做，那就慘了，理清頭緒都不是件容易的事情。

 

事實上，重構遠沒有上面描述的那麼簡單。比如，以前項目中一直使用ExtJS進行介面的開發，現在想減小JS的比重，因此想改用JQuery+HTML+CSS來替換Ext的控制項，那改造起來也是很複雜的事情。一次性全部更新的代價很高，出錯機會很大，並且不容易形成規範。需要像國家改革一樣形成試驗，逐步推廣。從這裡也可以看出，重構不一定是OO的重構，除非你達到了一切皆是OO的境界。