我們首先來思考一個問題：作為工程師，我們的價值是什麼？
筆者認為是——解決使用者問題。
我們的任何知識和技能，如果不能解決特定的問題，那麼就是無用的屠龍之術；我們的任何經驗，如果不能對解決新的問題有用，那這經驗就是過時的。工程師不是空談者，也不是理論家，再好的理論，再好的設計，不能落地變成產品，不能解客戶燃眉之急，那終究也是水中月鏡中花，遲早要被淘汰。能解決現實中的問題才能體現作為工程師的價值。
但是，所有現實中的問題，都不是抽象的，比如我們不會提出一個“人是什麼”“什麼是善”這樣的問題。我們要解決的問題，一定是特定場景下，加了一堆定語和描述，十分場景化的。比如：如何降低模組之間程式碼耦合度，如何解決高併發中的c100k問題，如何提高工程程式碼的可維護性等等。那麼，針對這些特定的問題，早就經前人踩坑，總結出來的被認為行之有效的方式，就慢慢的沉澱為一種被稱為“模式”的東西。從這個角度來說，演算法是模式，設計模式是模式，架構也是模式——不同層面的解決方案而已。
每個模式都描述了一個在我們的環境中不斷出現的問題，然後描述了該問題的解決方案的核心，通過這種方式，我們可以無數次地重用那些已有的解決方案，無需再重複相同的工作。簡單地說，模式就是在特定問題場景下，解決特定問題的固定的套路。
設計模式簡介
軟體行業的設計模式，起源於1994年由GOF合著的《設計模式 – 可複用的物件導向軟體元素》一書，該書首次提出了設計模式的概念，並且給出了23中經典的設計模式。此外講設計模式的《Head First》一書通俗易懂、老少咸宜，也值得一看。
使用設計模式是為了重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性。因為設計模式是一套被反覆使用的、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。是無數正反經驗教訓的最終結晶，是設計智慧的最終載體。
所有的設計模式都有一些常用的特性：模式名稱(a pattern name)，問題陳述(a problem statement)，解決方案(a solution)和效果(consequences)。模式名稱用來描述模式的問題、解決方案和效果；問題陳述是用來說明這個模式的應用的領域；解決方案描述了這個模型的執行；效果則是這個模式使用效果和權衡。
設計模式使程式碼編制真正工程化，是軟體工程的基石，如同大廈的一塊塊磚石一樣。專案中合理地運用設計模式可以完美地解決很多問題，每種模式在現實中都有相應的原理來與之對應，每種模式都描述了一個在我們周圍不斷重複發生的問題，以及該問題的核心解決方案，這也是設計模式能被廣泛應用的原因。
設計模式的主要作用
設計模式有兩個主要作用：
-
最佳的實踐
設計模式是長時間優秀經驗的沉澱，提供了軟體開發過程中面臨的一般問題的最佳解決方案。學習這些模式就是讓你站在巨人的肩上，看得更遠，學得更快，少走彎路。
-
開發人員的共同平臺
設計模式是程式設計師之間的共同語言，而且就像成語一樣凝練。例如，單例設計模式意味著複用單個物件，觀察者模式意味著一對多和解耦，“單例模式”“觀察者”寥寥數語就能告訴對方，你的應用場景是啥、你要解決啥問題、你大致是怎麼去編碼實現的，從而在程式設計師之間高效的傳遞資訊。
簡言之，設計模式就是最佳實踐。