計算機工程師做的工作某個方面和建築師差不多，尤其是做專案的時候。

既然是做專案，必然要考慮投入產出，所以產生了軟體工程的學科。軟體工程告訴我們如何控制專案，包括可行性到維護等方方面面的管理過程。

不過大部分的工程師並不關心那個，他們更多是思考如何技術上實現。

但是設計師必須意識到不同的方法會帶來不同的投入產出，所以有人根據前人的經驗做了總結，搞出了兩個東西：

1.設計原則 （指導性要求）

2.設計模式（設計套路）

後者主要是為了滿足前者而存在的。

有了這兩個東西，就可以較好地配合專案經理，對專案進行管控--主要實現進度和成功控制。

不過在開始正式闡述之前，我需要說說另外一個很重要的內容：開發規範。

我們把眼界放開一點，就會發現其實前文提到的兩個內容，不外乎人們的經驗：無規矩不成方圓。

某些微小團體可能並不怎麼關注這個，但是有個事情還是強烈建議先完成：定義屬於自己團隊的開發規範，讓程式碼看起來整齊劃一。

這個也可以算是某種程度的原則和模式的統一規範。

但我還是強烈建議團隊的成員必須掌握這些基本的東西。畢竟大部分人都是普通得不能再普通的個體，沒有天縱之才，沒有發明新的工具之前，就不要妄想無招勝有招了。

在工作的時候，最煩的就是沒有規範導致的一些問題，以及專案維護的時候，看一些亂起八糟的程式碼。

閒話少敘，本人由於工作需要，也簡單地瀏覽了下有關設計模式的東西，發現的確是有可用之處。

這些資料主要來自於

這些資料整體還是很完善，而且通俗易懂。建議可以在這裡學習，以便減少不必要的支出。

菜鳥網整理的設計模式挺多的。但實際工作的時候，大部分用不著，這和大家一個道理，好用的常用的就幾招。一些非常個性化的就只能使用於一些非常特殊的場景。

由於菜鳥網有詳細的資料，這裡就不一一重複了。下面只列出本人比較關注的一些內容

 如果我們認真看下已有的模式，會發現有些還是基本不用的，這些不需要刻意去理解，只需要記住有這個東西，在需要的時候，可以回來研究下。

 如果您的團隊主要是做一些常規的應用開發，其實不需要過分關注設計模式（雖然有的已經不自覺地使用了），因為大部分的此類應用用不著動太多的腦筋，大體簡單地複製貼上就差不多了。

 話雖如此，有備無患總是好的！