縱談軟體預構（一）——開篇

      非常偶然地學到了一個概念，叫預構。接下來的時間，就對預構的各個方面做下簡單的探討。

      首先，我們先來看下什麼叫軟體預構。聽到軟體預構這個詞，相信很多人第一個想到的詞都是“軟體重構”，我也不例外。但是這兩個詞完全是兩個概念。

      重構是對一個已完成的項目利用模式進行實際的設計，代碼上的修改。而預構是利用前人，或者曾經開發的經驗來進行現有軟體項目的開發。換句話說，預構是一種經驗流，每個人都在預構，只不過沒有接觸到這個詞罷了。只此而已。如果偏說預構和重構有什麼關係。我大概概括了下，就是預構的經驗是從重構中獲得的，預構可以減少重構的次數。

      好了，解釋過了這個詞。我想我該對我這個系列的文章重新做下簡介了。與其說我是在討論預構，不如說我在談我對軟體工程各個流程方面不同的理解和思想。

      廢話到此為止，現在開始正式的“預購”，在我的開篇文章中，主要就是說下“預構”的核心思想。

      從曾經的機器碼，到彙編，Basic,C,C++再到今天的C#,JAVA，F#等等。我們不難看出，軟體語言一代代地發展，趨勢和目標就是用最短的時間開發出最好的軟體。這裡有兩個字是核心：“好”和“快”！伴隨而來的是軟體工程的一個個新概念的誕生：XP極限編程，噴泉模型，螺旋模型之類等等。還記得學生時代第一次項目經曆——線上學習考試系統。當時初探軟體工程，小組會議上豪言我們要採用瀑布模型。當時學院給的項目時間是五個月。老師一周開一次項目會議，與其說是項目會議，不如說是不停地需求變更。於是我們就不停地總結需求，結果需求分析花了兩個多月，基本確定了下來。然後開始搞設計，沒有任何經驗的我又花了兩個月的時間，最後剩下了半個月開始寫代碼，接下來大家可以猜到，設計錯誤，介面設計不合理，模組無法整合。最後學院大筆一揮，.NET版本滾蛋，繼續採用JSP。

      痛定思痛，學會了迭代-遞增。接下來的項目開始越來越成功，從需求，設計，甚至到小組成員培訓，一共算在內，往往可以超額完成任務。直到現在，我依然堅持著這樣的流程：需求-->第設計一次-->編碼-->代碼最佳化-->設計重構-->需求變更-->第二次設計-->改善設計-->編碼-->代碼最佳化-->設計重構...........

      在《軟體預購藝術》中，引入了這樣一個詞：極致——抽象化到極致，關注點隔離到極致，可讀性到極致。對其中的觀點，我並不完全贊同，下面僅陳述我的觀點：

      1. 類型抽象極致化。我的意思是指初始化設計階段，每種資料類型盡量不要用int,double等實際類型表示。如Age這個概念，恐怕用實體資料類型描述要花一番心思。不能太大，不能太小，不能為小數，在初始設計時，把精力花在這些細節上是不好的。就乾脆寫成Age age更好些。等整體設計確定後再來關注這些細節。

     2. 可讀性極致化。這點不用我多說，沒有誰愛看沒有任何編碼規範的代碼。我個人基本不用任何簡寫，寧可名字很長，至少以後看起來不用動腦筋，有了智能感知，我也不用擔心拼字錯誤的問題。

     3. 物件導向適度化。在初學設計模式時，處處設計，樂此不疲。但在實際項目中，過度抽象，過度對象化並不是件好事。抽象是為了變化，沒有了變化就不要費力去抽象。

     最後，再套用一句話：“情境就是一切”。在山路上開著法拉利跑車不會被人羨慕，只會被人罵做神經病。一個優秀的軟體設計，架構師最大的優勢不在於他們的技術，而是他們的隨機應變的能力，也就是經驗流，回到主題，也就是“預構”能力！