程式設計師與建築師

軟體表示的是一種現實的關係，關係往往錯綜複雜，但是，有時內涵卻是一樣的。萬事萬物雖然形態各異，但是，巨集觀機械運動都符合牛頓運動定律。這種事物深層的內在聯絡有時候是不容易被發現的。而且，在你的軟體中，很有可能沒有這樣統一的定律。

所以，構建乙個**的世界，更像是建築師構築乙個大廈，而不是科學家發現定律。但，就像建築師需要力學知識

和美學知識，學習軟體的人，也需要一些基本的定律和原則構建這樣的大廈。

建築師需要考慮客戶對建築的使用靈活性。除了主幹不能變之外，房子的牆壁，裡面的裝修應該是可以改變的。不能一下子就把乙個東西給定死了，否則價值就不能最大化。同樣，軟體設計也要處理這樣類似的問題。

在學習了

資料結構，作業系統… 這些課程以後，你可能發現即使你學會了所有的演算法，也不能靈活應用到你的問題中，最後，你會發現，大多少問題實際上是乙個數學問題，你最應該學習的還是數學。你要把自己當作是乙個應用數學家，而不是寫**的小蜜蜂。

建築師有了力學知識，不一定能構建完美的大廈。而，你有了數學知識，有了完美的演算法，卻不一定能寫乙個完美的軟體。你還需要處理很多細節的問題與結構問題。一般來說，它還要下面的問題：

1.需求改變了，能不能很靈活的改動。

2.是不是對一些邊界條件上的值也能正確的執行。

3.對輸入的錯誤的值，是否能夠有正確的反應。

2，3往往是習慣問題，養成好習慣，一般能寫乙個比較好的程式。但是，1能做到確是很難。

所以，有人總結了一套設計模式，用於解決上面的軟體靈活性的問題。當然，軟體要能構建，首先要有個符合「力學原理」問題，也就是某種關係怎麼處理比較好，才不至於到了第10層樓，下面的地基承受不住了。這些也東西，有部分通用的東西也總結在了設計模式裡面了。

但是，即使對設計模式倒背如流，質量很差的軟體還是到處都是。關鍵不是背下那些模式，這些只是輔助你設計的一些東西。軟體大多數時候不需要最優解，只需要可行解，應為成本才是最重要的。

或者首先要問一下自己要造幾層樓。要是100層，那是一種設計方法，如果只有一層，那是另外一種設計方法。不是說，任何東西都要符合設計模式的規範。照搬照抄模式肯定不行。

首先要符合力學規範，然後是美學規範。很多人寫**，語不驚人死不休，一定要短，或者一定要用特別多的技巧，然後，只有

完美的藝術家才能欣賞他的**。在設計的時候，不應該首先考慮用上面模式比較靈活這樣的問題，或者，什麼演算法比較完美，先要把關係，模組，層次搞清楚，哪些是第一層，哪些是第二層。這些就是架構，它要考慮乙個軟體的如何合理的劃分能降低建造成本。劃分模組方法可以參考我以前的博文:

庖丁為什麼能解牛，是應為他對牛的結構非常清楚，知道**是骨頭，**是肉，只有弄清楚結構了，才比較好下手。結構搞清楚了，然後是一些細節架構的設計.比如，訪問資料庫的乙個模組，你的系統有好幾種資料庫支援，可能要用到介面卡模式。這樣可以實現統一的訪問介面。這樣逐步求精，解決軟體設計的問題。

程式設計師 與 建築師