軟件，自從被我們開發出來并交付使用以后，如果它運行得好好的，我們是不會去修改它的。我們要修改軟件，萬變不離其宗，無非就是四種動機：

1.增加新功能；
2.原有功能有BUG；
3.改善原有程序的結構；
4.優化原有系統的性能 。

第一種和第二種動機，都是源于客戶的功能需求，而第四種是源于客戶的非功能需求。

軟件的外部質量，其衡量的標準就是客戶對軟件功能需求與非功能需求的滿意度。它涉及到一個企業、一個軟件的信譽度與生命力，因此為所有軟件企業所高度重視。但是，就在所有企業高管把軟件外部質量放在高于一切的高度的同時，軟件內部質量卻長期為人所漠視。企業沒有保證軟件內部質量的措施，甚至因為需要趕工而肆意地降低內部質量的標準。這樣帶來的長期惡果就是，程序編寫越來越爛，運行效率越來越低，程序結構越來越讓人看不懂。當一群群剛剛畢業的大學生游走在這堆寫得很爛的代碼中時，他們開始沉淪，開始天真地以為代碼就是這樣寫的（真是毀人不倦呀）。當我們的軟件企業培養出一批批質量不高的開發人員，開發出一個個質量低下的軟件系統時，它們開始發現軟件維護成本越來越高，最終不得不收獲自己種下的惡果。

要提高軟件內部質量，毫無疑問就是軟件修改的第三個動機：改善原有程序的結構。它的價值是隱性的，并不體現在某一次或兩次開發中，而是逐漸體現在日后長期維護的軟件過程中。高質量的軟件，可以保證開發人員（即使是新手）能夠輕易看懂軟件代碼，能夠保證日后的每一次軟件維護都可以輕易地完成（不論軟件經歷了多少次變更，維護了多少年），能夠保證日后的每一次需求變更都能夠輕易地進行（而不是傷筋動骨地大動）。要做到這幾點其實并不容易，它需要我們持續不斷地對系統內部質量進行優化與改進。這，就是系統重構的價值。

為了有效提高軟件的內部質量，我們在系統重構中應當做哪些事情呢？首先是提高軟件的可讀性、易于閱讀。軟件要可讀，并不是添加幾行注釋那么簡單的事兒，首先是軟件的業務邏輯要清晰。一個業務流程可能其處理過程可能非常復雜，如果在一個函數中順序地一行一行寫下來，可能需要寫數百行，甚至上千行。比如，我們要實現這樣一個需求：像Spring那樣從一個或者數個配置文件中讀取XML，然后根據XML依次去創建每一個bean，將每一個bean放到beanFactory中。如果沒有經過精心地設計，而是隨性地一行一行寫，要實現這個功能沒個幾百上千行代碼，想想都難。但如果我們換個思路，在入口函數里僅僅調用幾個頂級方法，比如findXmlFile()、readXmlStream()、buildFactory()，然后依次去實現這幾個頂級方法，程序結構就會變得清晰而易讀。請看這段示例代碼：

    
public abstract class XmlBuildFactoryTemplate {
	/**
	 * 初始化工廠。根據路徑讀取XML文件，將XML文件中的數據裝載到工廠中
	 * @param path XML文件的路徑
	 */
	public void initFactory(String path){
		//尋找XML文件，讀取數據流
		InputStream inputStream = findXmlFile(path);
		//解析XML文件，返回根
		Element root = readXmlStream(inputStream);
		//根據XML文件創建類，放入工廠中
 		buildFactory(root);
	}
	/**
	 * 讀取一個XML的文件，輸出其數據流
	 * @param path XML文件的路徑
	 * @return InputStream文件輸入流
	 */
	protected InputStream findXmlFile(Stringpath) {
		......
	}
	/**
	 * 讀取并解析一個XML的文件輸入流，以Element的形式獲取XML的根，返回之
	 * @param inputStream 文件輸入流
	 * @return ElementXML的根
	 */
	protected Element readXmlStream (InputStream inputStream) {
		......
	}
	/**
	 * 用從一個XML的文件中讀取的數據構建工廠
	 * @param root 從一個XML的文件中讀取的數據的根
	 */
	protected abstract void buildFactory(Element root);
}

  

在實現這幾個頂級函數的時候，我們還會將一些比較獨立的功能分解出去，形成類與接口，比如這里的findXmlFile()，它可能會以各種方式去尋找XML文件，這時把這些功能提取出來，形成Resource接口和它的多個實現（如圖1.1所示），為findXmlFile()所調用。如果我們將這個復雜的功能設計成這樣，則毫無疑問，系統可讀性將大大提高。



此外，在面向對象的世界里，我們設計的類、方法、關聯，應當與現實世界中的事物、行為，及其相互的關系對應起來。現實世界有什么事物，這些事物都應當有什么行為，相互之間是什么關系，則我們在軟件世界里就應當設計什么類、什么方法和它們之間的關聯關系。只有這樣的設計才是最易于為人所理解的設計，這就是“領域驅動設計”的思想 。在系統重構中，我們將使用“抽取方法”來分解難于閱讀與維護的大函數，用“抽取對象”來分解無所不能的大對象。

系統重構要干的另一件事情就是使軟件易于維護、易于變更。軟件需求總是變得越來越復雜，這是無法改變的客觀事實。在添加新功能的同時，我們既要保證原有代碼的有效性，又必須有效地復用原有的代碼。這是多么矛盾的一件事兒啊！怎么辦呢？看我在后面一步一步給你分解……

大話重構連載首頁： http://fangang.iteye.com/blog/2081995
特別說明：希望網友們在轉載本文時，應當注明作者或出處，以示對作者的尊重，謝謝！

大話重構連載5：軟件修改的四種動機