軟件開發演化史：尋找“銀彈”之道
軟件開發方法的演化史絕對是一部尋找“銀彈”的歷史，即研究管理軟件復雜度方法的歷史。我個人的體會：開發復雜的軟件系統的確，呃，復雜，由此帶來不菲的時間和金錢的花費。下面我們看一下5種軟件方法論的發展及應用。
軟件方法論之結構化編程（Structured programming）
在結構化編程思想提出之前幾年，我就已經開始了（始于1973）職業編程生涯。結構化編程涉及正確使用代碼塊，過程調用以及各種循環結構。還有一條黃金法則：go-to是有害的。
程序結構應該清晰、流程控制易于理解，這點在今天看來是毋庸質疑的。同時我也認為，結構化編程的想法已經融入后來所有的編程方法論之中。
軟件方法論之面向對象編程（Object oriented programming）
面向對象編程(OOP)方法自然也是從結構化編程思想演化而來。OOP通過封裝代碼與代碼使用的數據來管理軟件復雜度。我們習慣于處理真實世界的物理對象，在OOP中，我們可以為真實世界的對象建模（如編寫模擬程序，這也是OOP概念開始提出的地方），并對非具體概念如進程、信息組織方法等建立軟件模型。
程序里“對象”維護自己的內部狀態，這與結構化編程非常地不同。在結構化編程里面，代碼是以一種結構化的、容易理解的方式組織，全局共享數據對于軟件系統的各個部分都是可見的，包括那些并不需要訪問或修改那些共享數據的部分。
軟件方法論之設計模式（Design patterns）
睿智的人關注他們世界的各種模式。學生時候，我們可能會注意班上同學的良好學習習慣所形成的學習模式帶給他們優異的成績。我們學習烹飪時，可能注意到有經驗的廚師做菜的模式，如烹飪前先備料，加調料的時候不斷的嘗一下等。
在軟件開發領域，設計模式的使用是基于對某些項目失敗而另外類似項目成功的觀察（這些也可能是管理模式，計劃模式，測試模式等等）。在軟件設計過程中，模式的使用是基于對一些通用的設計方式在成功項目中的重復使用的進一步研究的結果。
軟件方法論之極限編程（Extreme programming）
極限編程基于對客戶需求的快速確認，快速開發與快速交付使用。極限程序員與客戶交流過程中使用簡單的設計，并以迭代方式優先開發軟件最被需要的部分。
極限編程與傳統開發方式背道而馳。傳統開發方式是開發者與客戶花費大量時間來試圖事先將一切細節寫入文檔，這種開發方式占用相當長的時間。有經驗的開發者知道，階段性的完成編碼對設計流程有正面影響。極限編程尤其適合那些需求復雜、或需求事先無法達成一致的情況。
在學習本書中的UML時候，我們會涉及個人如何使用軟件系統的例子。極限編程有類似的概念，叫做"user stories"（這個詞不知道應該如何正確翻譯－by譯者）,即客戶提供的他們感覺軟件系統應該如何使用的信息。User stories會被用來估計開發時間，并幫助建立自動測試用例——用于開發測試和交付用戶測試。
極限編程經常被描述為——對于我而言更加容易理解——測試驅動的編程，在編碼前即編寫測試代碼！然后編寫足夠的能通過測試的代碼即可。在所有單元測試通過之前，軟件代碼不允許改動。使用像JUnit 這樣的工具來編寫自動測試。
軟件方法論之面向切面編程（Aspect oriented programming）
面向切面編程(AOP)后面的主要思想是對軟件系統不同關注點的分離，開發者通過攔截方法調用并在方法調用前后添加輔助代碼來實現。切面可以在對象里除了行為之外新定義特定的切面數據(aspect-specific data)。原理上，這種哲學允許系統開發更加模塊化，這種模塊化的實現通過程序員不同的關注點來驅動。對于Java程序員，我推薦看一下AspectJ項目(eclipse.org/aspectj). 下面是從AspectJ站點引用的：
”AspectJ 通過對以下關注點的橫切達到簡潔的模塊化：錯誤檢測和處理，同步，對上下文敏感的行為，性能優化，監控及日志，調試支持，多對象協議”
無論是免費的Eclipse還是商業的IntelliJ Java IDE都支持AspectJ. AspectJ 是Java語言的擴展，需要預處理。我在為開源web框架Jaffa做收費咨詢的時候用過Java的切面。在使用動態語言像Ruby和Lisp時，切面更加有用。Ruby和Common Lisp允許在任何源文件為一個類增加方法，這種優勢意味著特殊的目的以及特定應用的對庫的擴展可以與庫的源代碼相分離。
一個簡單的使用切面的例子如下：你有一個類庫來處理收發郵件，然后來了一個商業方面的需求，按收信人和發信人分類，記錄郵件的數目和大小。分離的切面就能讓你通過代碼注入的方式來實現對郵件的監測，而不需要改變原類庫的代碼。這會讓類庫作者更加容易地維護他們的代碼，不用增加對郵件監測的代碼。
本文來自metaphy的博客：《軟件設計和開發的簡史》
【編輯推薦】
