眾所周知, 軟體開發時遵守一個規範的設計模式非常重要, 學習行業內主流的design pattern往往能夠為你節省大部分時間.

根據我2年的全棧經驗, 在Web應用程式領域最流行的, 並且若干年內不會過時的設計模式套餐分別是: 前端的MVVM, 後端的MVC, 以及中間的restful api設計模式, 這三個設計模式的搭配非常完美, 以至於幾乎所有的網際網路服務都效仿這個標準來開發應用.

但是很遺憾, 很多新人還是喜歡培養自己的程式設計風格, 甚至認為自己的開放方式比主流的設計模式在某些方面更優秀, 如果有這個思想說明你的確是個聰明,積極的程式設計師, 但一定沒有太多經驗, 因為dalao們開發任何一款app都會遵循相關的設計模式, 寧願放棄也許存在的更好的'冷門模式',也要從眾, 這就說明主流模式的存在一定有他們存在的意義.

學習設計模式的好處

摘自書上:

幫助我們將應用組織成容易瞭解，容易維護，具有彈性的架構，建立可維護的系統，要訣在於隨時想到系統以後可能需要的變化以及應付變化的原則。

1、設計模式能讓程式設計師之間更有默契

程式設計師A：我這個專案用了XXX設計模式

程式設計師B：那我大致瞭解你程式的設計思路了, 我知道該怎麼閱讀你的程式碼了!

2、易維護, 易擴充套件

PM：今天客戶有這樣一個新需求…你看能不能實現[害怕]

程式設計師：明白了，還好我使用了XXX設計模式，所以改起來很快

3、設計模式讓你快速的開發一個專案, 減少思考的時間

程式設計師A：你怎麼想到要這樣去構建你的程式碼?

程式設計師B：在我學習了XXX設計模式之後，對領導的需求立刻就能抽象成相關的架構, 非常舒服!!

所以說, 遵守設計模式是為了應對新的變化和新的'人'

全棧設計模式的歷史

資料顯示分離時代

現在後端MVC太經典了, 但mvc是從前端的'資料顯示分離'進化而來的, 

原來舊PC時代, 大概上個世紀的'資料顯示分離'設計模式只是適用於單機的app, 不參與任何網路服務, 比如小遊戲, 這時候將資料和顯示分成2層非常完美, 但是後來隨著本地資料庫和其他永久性儲存的解決方案出現以後, 2層分離明顯不夠用了, 於是就有了MVC的雛形...

前端mvc時代

這時候mvc還未發展成熟, 其中的中間層'controller'僅僅是起到一個過濾作用, 同時為了滿足多人合作開發應用的需求, 也使得這個'偽mvc'的3層結構變得異常多樣化, 這個特殊時代前端的設計模式是五花八門的, 非常混亂, 可惜我也沒經歷過那個年代(大概在web1.0早期), 但可以肯定正是那時候最早的一批web開發者的努力探索, 才有我們今天優秀的設計模式可參考.

前後端分離時代

後來慢慢的單機app不再流行, 取而代之的是網路app, 也就是web應用, 這時候mvc的設計思想正式被規範化了, 這裡規定了, 中間層作為主線控制邏輯, 資料層和顯示層作為輔助模組而存在, 這時候架構師思考應用的'主線劇情'始終繫結在中間的'邏輯控制層'

這個時代仍然是過渡時代, 因為分離, 形成了前端mvc+後端mvc的混沌局面, 這時候產生了一個核心問題: "業務的重心放在前端還是後端?"

RESTful API的誕生 --- 後端已成熟

restful api的誕生具有劃時代的意義, 因為它定義了所有網際服務的介面規範(不是標準), 並且將所有伺服器提供的服務都歸納為'增刪改查'.

REST全稱是Representational State Transfer，中文意思是表述性狀態轉移。 它首次出現在2000年Roy Fielding(HTTP規範的主要編寫者之一)的博士論文中。 他在論文中提到："我這篇文章的寫作目的，就是想在符合架構原理的前提下，理解和評估以網路為基礎的應用軟體的架構設計，得到一個功能強、效能好、適宜通訊的架構。" 如果一個架構符合REST的約束條件和原則，我們就稱它為RESTful架構。

RESTful設計模式真正成熟是在2009年左右, 移動網際網路全面來襲的時候, 完全遵守了原web2.0時代尚未飽和的REST(因為還有許多歷史遺留的過時模式), 幾乎所有手機app無一例外的使用了Http(s)來實現自己的業務, 甚至很多直接照搬了html那一套框架, 移動網際網路來的太猛烈, 沒有時間全部定製自己的技術和設計模式, 所以http+rest此時成為壟斷性的行業規範.

REST是建立在HTTP之上的哲學, 當然也完美遵循了http的request和response一一對應的經典模式, 可以說, REST是HTTP的深刻總結, HTTP是REST的完美實現.

除此之外, restful和mvc也完美的結合, 成為後端的開發標準, restful主要體現在後端mvc的邏輯控制層, 進行資料轉發接收以及使用者驗證, 當今很多web框架都支援restful+mvc,比如Express.js, .Net, Apache

推薦ruanyif的部落格, 裡面詳細介紹了rest的思想:

http://www.ruanyifeng.com/blog/2018/10/restful-api-best-practices.html

MVVM的誕生 --- 前端已成熟

移動網際網路之後,後端已經穩定, 前端也在慢慢發生著變革, 前端由傳統的mvc漸漸演變成MVVM:

什麼是MVVM？MVVM是Model-View-ViewModel的縮寫。mvvm由微軟提出, 它的誕生是為了解決前端的問題: 前面說前後端分離時代的新問題'業務重心放前端還是後端'後來的趨勢是, 越來越多的計算任務放在了前端, 只將和安全有關的任務放在後端做, 這時候前端人員的工作量異常的巨大, 於是大家希望能夠將'資料繫結''這樣的體力勞動讓系統自己負責, 於是就有了mvvm, mvvm的核心就是資料繫結, 換句話說是讓資料與顯示完完全全分離.

基於這樣的新趨勢, 各路大仙紛紛推出了自己的mvvm框架, 比如瀏覽器領域的vue,react和angular, 但是很遺憾的是dom本身還不能完美支援mvvm, 目前想要使用只能藉助框架, 另一個後起之秀Qt則原生支援了資料繫結, 相信瀏覽器也會慢慢的支援..

平行層的多元化

目前為止, 大勢已定: 前端mvvm, 後端mvc, 中間restful成為每家每戶的必備工具, 但是這個大體架構下的內部架構是可以根據不同的業務而定製的, 因此出現了很多'平行層', 比如和資料訪問層平行的模型層, 和入口檔案平行的配置檔案, 還有和其他輔助類平行的工具層, 因此真正專案中的層次是不止3層的, 當然這就完全沒有規範了, 還是根據實際情況而定吧.

模組化程式設計統一每一層的細節

最後我想談談, 在程式碼規範上, 我們主要遵循一種叫模組化程式設計的設計規範, 在JavaScript中體現為函數語言程式設計風格, 模組化的本質上雖然是'分離', 但效果上卻把零碎的邏輯整合到一起, 更利於開發者思考.

UI設計模式

為了讓使用者更好的理解UI的功能, 在UI設計上最好也遵守主流的設計模式比如alphabet的material和microsoft的universal等.

專案構建模式

隨著專案構建釋出的流程日趨複雜, 在構建(building)領域也正在形成統一的規範, 當然現在8102年還沒有形成...那就不談了吧, 但要意識到這個趨勢

設計模式的"隱患"

並不是說遵守主流設計模式就百利而無一害, 設計模式都是有代價的, 我們瞭解一下就好:

1. 高可擴充套件性會犧牲高內聚低耦合度

設計模式幾乎都體現了高可擴充套件性, 以為可以滿足性的需求, 但是仔細想想可擴充套件意味著介面預留豐富, 層次劃分多級, 整個系統的體積也會很大, 自然會導致內聚性的降低, 效能的衰減, 當然很多情況下這是不可避免的, 我們仍然選擇了犧牲硬體成本來保證邏輯上的安全, 畢竟硬體資源越來越廉價.

2. 讓你變得更懶惰:)

專案一上手就急著找相關的設計模式, 一定程度上減少了自己思考的時間, 同時, 設計模式在實際情況上的實現也有無數種方案, 如果新人一開始直接照搬別人的模式拒絕自己思考, 甚至不理解整個模式的工作流程, 這該是一件多麼可怕的事情.

3. 選擇錯誤的代價

設計模式雖然讓你的專案更易修改, 但如果你想更換整個設計模式就是件很痛苦的事情了, 如果你發現整個系統從一開始就設計失誤, 不僅日後再難微調, 還會造成極大的安全隱患. 所以我的建議是, 如果你是新手, 或者你對一個全新的設計模式0瞭解, 那就不要急著上手, 學會先思考, 針對目前的專案設計一個自己的設計模式, 思考的同事考慮擴充套件性, 可讀性, 功能性, 效能等因素, 之後再拿這個自己的設計模式到網際網路上尋找類似的模式, 或者像前輩請教, 如果發現了一個形態不同但本質一樣的設計思想或者看到了更好的解決方案, 那就說明你成功了.