前端要不要學習設計模式
始終認為每個行業都有自己的特點，各自的專業性。一個開發工程師如果不知道電腦是哪些基本硬體組成，那麼我們大機率都會認為這個人非常不專業。那麼前端要不要學設計模式呢？設計模式跟前端有多大關係呢？
前端工程師首先是一個工程師，既然是一個軟體工程師，那麼類似設計模式、資料結構、網路相關等基礎知識點都是必須的，而不是要不要學的問題，一個工程師應該具備這個領域特有的知識體系，而不是零散的知識點。
工程師核心是什麼
網際網路的這些年，技術革命就沒消停過。就比如前端來說，框架、庫，從原生 JavaScript 開始寫，然後寫 jQuery、寫 zepto、寫 Angular，寫寫寫，一直寫到現在的 Vue/React 等。各個技術概念、框架、庫都迭代的非常快，難道工程師的核心僅僅是會使用某某框架、庫嗎？難道會使用java 的程式設計師一定比不會用java的程式厲害嗎？
能夠決定一個工程師的本質的，不是這些瞬息萬變的技術點，而是那些不變的東西。
不變的東西，說的就是這種駕馭技術的能力。
- 編碼能力
- 設計思維
- 計算機基礎
- 技術廣度、深度
- 解決問題的能力
- 溝通能力
- 文件能力
編碼能力具體來說，它分為以下三個層次：
- 能用健壯的程式碼去解決具體的問題；
- 能用抽象的思維去應對複雜的系統；
- 能用工程化的思想去規劃更大規模的業務。
這三種能力在你的成長過程中是層層遞進的關係，其中後兩種能力可以說是對架構師的要求。事實上，能做到第一點並且把它做到紮實、做到嫻熟的人，已經堪稱同輩楷模。
用健壯的程式碼去解決具體的問題的能力。這個能力在軟體工程領域所對標的知識體系，恰恰就是設計模式。所以，要成為一個靠譜的開發，先掌握設計模式。
設計模式到底是什麼
維基百科中對設計模式的定義是這樣的：在軟體工程中，設計模式（Design Pattern）是對軟體設計中普遍存在（反覆出現）的各種問題，所提出的解決方案。
我的理解是設計模式並不是一個虛無的東西，而是經過各種軟體開發人員在特定的場景下提煉出來怎麼樣寫程式碼的一種思路、一種解決方案，按照他們的思路可以讓程式碼更加容易維護、擴充套件。也就是通常說的健壯的程式碼去。
設計模式基本原則
設計原則是設計模式的指導理論，它可以幫助我們規避不良的軟體設計。SOLID 指代的五個基本原則分別是：
- 單一功能原則（Single Responsibility Principle）
- 開放封閉原則（Opened Closed Principle）
- 裡式替換原則（Liskov Substitution Principle）
- 介面隔離原則（Interface Segregation Principle）
- 依賴反轉原則（Dependency Inversion Principle）
在 JavaScript 設計模式中，主要用到的設計模式基本都圍繞“單一功能”和“開放封閉”這兩個原則來展開。
設計模式核心思想
在實際開發中，不發生變化的程式碼可以說是不存在的。我們能做的只有將這個變化造成的影響最小化 —— 將變與不變分離，確保變化的部分靈活、不變的部分穩定。
這個過程，就叫“封裝變化”，這樣的程式碼，就是我們所謂的“健壯”的程式碼，它可以經得起變化的考驗。而設計模式出現的意義，就是幫我們寫出這樣的程式碼。
設計模式的核心思想，就是“封裝變化”，將變與不變分離，確保變化的部分靈活、不變的部分穩定，程式碼有良好的可維護性、可擴充套件性；
簡單的說就是觀察你整個邏輯裡面的變與不變，然後將變與不變分離，達到使變化的部分靈活、不變的地方穩定的目的。
23種設計模式分類
無論是建立型、結構型還是行為型，這些具體的設計模式都是在用自己的方式去封裝不同型別的變化。
建立型模式：封裝了建立物件過程中的變化，比如下節的工廠模式，它做的事情就是將建立物件的過程抽離；
結構型模式：封裝的是物件之間組合方式、以及通訊的變化，目的在於靈活地表達物件間的配合與依賴關係；
行為型模式：則將是物件千變萬化的行為進行抽離，確保我們能夠更安全、更方便地對行為進行更改。
參考：
《 JavaScript 設計模式》