小夥伴們，大家好！
這次來填坑了，關於前後端分離這個話題，我必須要交作業了，因爲在私信裏實在被問得太頻繁了。
前後端分離的開發模式，這兩年確實被炒得如火如荼，導致這個話題也成了面試極其愛問的一個問題，尤其是換工作、跳槽，之前不管你是做後端，還是前端，都可能會涉及。
面試官常問：
誒？你對前後端分離有什麼理解啊？
你覺得一個項目應該如何實施前後端分離呢？
很明顯，這是一個開放性問題，但是卻能考察出選手們技術關注點的層級。
其實在回答這個問題時，尤其程序員，一談到這個問題，上來就一頭扎進了某項具體的技術中去了，比如什麼：Ajax異步請求、 Vue組件化框架、 RESTFul接口規範、 API接口數據約定、 Mock平臺和數據等等。
恕我直言，這估計很難成爲面試官內心想要的答案。
因爲站在面試官的角度，這個問題大家如果僅僅以某項具體技術、框架來切入，他會覺得你的理解其實很侷限。因爲很有可能你只知道有前後端分離這個概念，卻不知道爲什麼要做前後端分離這件事情。這尤其對培訓班出來的小夥伴，如果只談到這個深度，就非常危險了。
而且社會上很多公司、團隊的一個誤區就是：爲了做前後端分離而做前後端分離。
從歷史淵源說起
以前很長的一段時間裏，在一個搞開發的公司裏，其實後端工程師是比較有 “門面” 的，往往也是項目和公司的核心團隊。這種觀念甚至影響了現在很多的應屆生求職，都擠破頭想去後端開發崗。
那個時候前端開發肯定也是有，但直言不諱，那時候的前端開發人員壓根就沒什麼話語權和公司地位，僅僅是一小撮人散步在團隊的小角落，甚至在很多團隊裏，前端開發都是後端工程師兼任的。
你回想一下，那個年代用的JSP技術不就是這個樣子嗎？我們就以JSP舉例。JSP就是前、後端耦合在一起混着做，套個模板可以把大家弄得死去活來。
這種開發模式在以前那個互聯網服務還不是那麼繁榮，Web化趨勢還不是那麼明顯的年代，發揮着巨大的作用，大家用得還算開心，畢竟頁面不復雜嘛。
但隨着社會信息化程度加深，各種各樣服務都Web化以後，很多前端展示的東西都變得複雜起來。不信你去數一數淘寶這種網站的頁面樹，簡直太複雜！這時像JSP這種模板技術就沒辦法高效開發。
究其本質原因，還是因爲前端這時候並沒有工程化、模塊化和可複用化。但那時候的後端不一樣，一個Spring這種工程化的開發框架就可以撐起半邊天！
所以你想想，這時候開發必然會出現各種不協調、低效率、甚至推諉扯皮的問題。所以從公司項目管理的角度來看，這種開發方式就會非常影響開發效率，所以項目管理者們開始想辦法來解決這個問題。
一條永恆的法則！
所以你們說應該如何解決上面的問題呢？
解耦唄！
大家有沒有發現，在軟件領域，任何複雜問題面前，高內聚、低耦合這個法則幾乎都能見效！
所以：
前、後端的事情分開來做吧！
我們要把前端開發的責任從後端工程師身上拿掉！
我們要給前端開發工程師一個單獨的崗位和責任領域！
我們要給前端開發者們正名！
我們不能讓前端開發總是用野生的模式開發，不能一天到晚到處copy html片段，js片段來人肉試錯！
前端開發也需要工程化、項目化的思維來做！
所以這纔是前後端分離開發模式最開始的來源。
說來說去，前後端分離與否，它本身並不是一個技術問題，而是一個項目管理的問題。
自此開始，前端獨立出來了，單獨行動了。那技術上的問題又怎麼解決呢？
組件化框架革了誰的命？
自學過前端開發的小夥伴可能會有一種感覺就是：我去，前端這玩意怎麼這麼瑣碎和玄學！知識非常零碎、不易掌握、學了就忘！
很多人學習、甚至工作了都還是東拼西湊、複製粘貼，copy代碼段、東拼西湊，靠往上堆積來完成需要的頁面和效果。
你會感覺前端這玩意它就是沒有Java後端開發這麼有邏輯、易管理、可複用！
所以直到像 Vue.js， React.js等這些前端組件化框架的出現，它才從本質上顛覆了前端開發的遊戲規則！我們稱它前端組件化框架，但我們更願意叫它前端工程化框架。因爲自此開始，大家都遵循一套體系來進行約束性開發，前端開發邁向了工程化、組件化、迭代化之路！
而且前端代碼也更好複用了。自從有了 Vue.js等這種組件化框架的出現，別人寫的現成按鈕、菜單、佈局，我們直接拿過來用得不是挺爽嘛！典型的比如像餓了麼的 ElementUI，以及螞蟻金服的 AntDesignUI，這擱以前哪能做到。
而且隨着 Node的出現，前端開發可以藉助 Node來開發各種各樣的工具來輔助高效的開發，比如各種包管理器、預編譯工具等等，這也是前端開發步入工程化的一個重要的方面。
前後端分離如何落地？
換句話說：到底怎樣做纔是一個比較優雅的前後端分離呢？
一個正常的軟件開發可以簡化成四大步：設計、開發、測試、部署，所以真正的前後端分離應該滲透到每個步驟中去。
第一個階段：設計階段
設計的第一個層面當然是系統設計：後端系統設計較好理解，主要是系統架構、數據庫、中間件、緩存等，主要考慮性能、容量、擴展性、維護性；那前端也應如此，假如網站非常複雜，頁面極其多，這時前端項目架構也需要做好規劃，儘量滿足長期演進、可迭代的目標。
設計的第二個層面就是接口設計：前後端系統通過接口進行交互，這時模型（ Model）層面的接口約定極其重要，包括：接口請求方式、數據類型、數據格式等。開發前，前後端雙方評審到位，都認可之後方可進行下一步開發，否則未來在開發過程中，前、後端開發工程師永遠在爲了某個破接口扯來扯去！
第二個階段：開發階段
各自按照事先評審好的接口獨立開發，互相無需扯皮。
現如今，前端在諸如 Vue、 React等當下火熱的組件化框架的加持下，的確可以獨立驅動頁面，數據則從事先規劃好的 Mock服務器去拿，完全不依賴於後端。
後端則只需要把接口寫好，按照先前評審好的約定提供數據。不管後端用Java的 SpringBoot，PHP的 Laravel，亦或是Python的 Django、 Flask，這些都跟前端沒關係。而且後端一套接口可以提供給多種類型的前端使用，譬如：Web網頁、手機APP、微信小程序等等。
第三個階段：測試階段
基本上要保證的是，前後端獨立可測試。前端主要就是頁面、跳轉、展示、輸入、傳參、響應數據的展示等；後端主要則考察數據格式、校驗、異常情況、數據一致性甚至一些權限問題。
最後一個階段：上線部署
前後端項目獨立部署，這個很關鍵！在以前的JSP模板時代，前端的html頁面、css樣式、js效果均由後臺來驅動。那個時候所謂的項目部署上線，其實指的也就是後端項目的部署，前端“所謂的”發版本，還是得求着後端來做的。
前後端分離後責任就清晰了，前端項目單獨部署。前後端發佈上線完全獨立，雙方可以按照各自的版本規劃來發布版本，前端發版本不再受後端約束，後端發版本前端也可以不知道，互相透明瞭。
還有一個必須提的就是，很多公司裏，後端項目都是通過諸如 Jenkins等 CI系統去做持續發佈，一鍵部署，同理前端項目也應該擁有自己的CI系統。
這玩意真那麼邪乎？
最後一個問題： 前後端分離吹得這麼邪乎，它真的就沒有缺點嗎？
這個問題就要回歸文章開始的討論了，即：爲什麼會有前後端分離這件事情的出現。
怕就怕很多公司爲了前後端分離而做前後端分離。前後端分離需要成本！尤其當你想做一個徹徹底底的前後端分離，不管是人力成本、開發成本、工具成本、還是部署成本，都是不小的。
不顧實際需求，強行前後端分離開發只會帶來麻煩，因爲只要落地過程中某一步做得不徹底，就會帶來很多負擔！畢竟並不是所有項目都適合前後端分離！
還是那句話，前後端分離與否，它本身不是一個技術問題，而是一個項目管理的問題！
每天進步一點點！Peace！
2020.02.19晚