真正接觸前後端分離模式也就幾個月的時間。本文屬於自己對前後端分離模式的一些總結，主要來源於針對之前的後端做資料渲染與分離模式的一些對比。近期會針對一些常見的開發模式做一些分享，如果對你有幫助，給個關注吧!!!
什麼是前後端分離
前後端分離從埠劃分就是將瀏覽器、客戶端分為前端，提供真實服務的軟體就成為後端。從開發語言的角度劃分後端的程式語言和前端的程式語言，例如Java是做後端真實資料服務的，JavaScript、HTML是做前端業務資料的展現與使用者行為操作的。
為什麼會出現前後端分離
A.為什麼會出現前端和後端分離模式，這得從有前後端分離開發模式之前的開發模式說起。我們先看下面兩張圖。
第一張圖是非前後端分離。
1.首先，我們通過圖片可以看出，一個專案的開始從產品經理，其次是設計工程師，其次是前端開發工程師……最後才是運維工程師進行專案部署。這樣一個專案才算的上真正的開發完成了。
2.這樣的開發模式全程是一個序列的模式，從外觀就有點像一條龍服務的模式，後者依賴於前者。用程式設計中的一個詞語就是，高藕和。
3.
第二張圖是前後端分離。
1.首先，我們通過這張圖片可以看出，一個專案的開始同樣是從產品經理，接著就是設計工程師負責。
2.最重要的一點，我們看設計工程師在負責的同時，後端工程師和前端工程師都在同樣的進行開發，這樣三者是處於並行進行。
3.然後設計工程師設計完之後，交付給前端工程師，後端開發工程師完成之後可以和前端工程師做對接。
4.這三者完成之後，接下來就是測試工程師，最後同樣的是運維工程師負責。這樣一個專案才算的上真正的開發完成了。
5.通過這種模式，我們不難看出，在產品經理完成之後，不再是單獨的設計工程師完成之後交給前端工程師，然後在交給後端工程師，而是三者可以處於並行的一個狀態。
B.上面談完了，我們接下來分析總結一下非前後端分離模式的缺點。
1.開發效率低。
通過上面的圖一，我們看的出每一個環節都依賴進行，難免延長了開發週期。
2.整個團隊的協作耦合度高。
環節層層依賴。如果某個環境進行了修改，其他的環境就得收到影響。
3.團隊容易甩鍋。
當專案出現問題之後，團隊成員很容易將一些責任推到其他的環節上面。
4.難以處理越來越複雜的業務。
隨著現目前的業務發展趨勢，業務也越來越複雜。例如，一些頁面互動效果，資料處理。傳統的模式很難支援這樣的業務場景。通過前後端分離，前端負責對應的互動業務，後端負責資料的處理。
5.使得程式碼的耦合度更高。
這裡可以從一種軟體設計模式來分析。那就是MVC模式，模型層(M)負責資料庫層面的操作，控制層(C)負責處理邏輯，檢視層(V)負責資料渲染。這是一種很不錯的軟體設計模式。但在不做到嚴格規範的情況下，仍有很多的程式開發者，在控制層C輸出一些檢視層V的業務程式碼,這樣的程式碼似的程式碼的耦合度更高，同時也難以維護。
前後端分離有什麼好處。
綜上B點弊端，我們不難分析出前後端分離的一些好處了。
1.提高開發效率。
2.降低的軟體設計的耦合度。不管是前端還是後端，都可以針對不同的端，實現一些工程化的東西。
3.提高了處理複雜業務的能力。後端可以只專注後端業務，前端可以專注於前端的業務。
前後端分離有哪些缺點
1.團隊溝通成本。
每個環節都需要保證溝通、協商好，否則很容易導致團隊混亂，因此前後端分離模式對團隊協調也是有著較高的要求。
2.不利於搜尋引擎抓取。
因為搜尋引擎看的是html原始碼，不能執行js，也就無法獲取js動態從ajax抓的內容。
3.專案維護成本。
前後端分離，後端的程式碼和前端的程式碼都需要單獨部署。在開發中也需要針對開發需求部署不同的環境。
4.增加繁雜的配置。
前後端分離，需要設定跨域一系列的其他操作。同時也會針對前後端的一些監控處理。都無疑增加了工作量。
前後端分離涉及到軟體開發的哪些環節
所謂的前後端並不是單純的指前端工程師負責的內容和後端工程師負責的內容之間可以獨立進行。總體歸納如下幾點:
1.產品設計
2.設計
3.前端開發
4.後端開發
5.測試
6.部署
這幾個環節，其實很多都可以並行執行。
1.例如，在產品設計好之後，能夠具體確定哪些功能，前後端工程師可以協商介面、介面引數等需要對接的內容，設計師可以同時負責設計。
2.當定義好了專案的一些規範，前後端的開發人員在開發的過程中，可能會需要一些模擬資料，這時候後端開發人員並未開發出對應的介面，那怎麼辦呢？就可以事先使用mock模擬一些資料，供前端人員呼叫，後端人員開發完成之後，前端直接呼叫真實資料。
3.在前後端開發過程中，測試人員可以針對前端人員開發的功能進行前端除錯，例如UI還原、使用者互動缺陷等。測試人員也可以針對後端開發人員的介面進行資料除錯。
4.最後運維工程師在前端和後端工程師開發過程中，可以針對前端的環境進行一些列的搭建，也可以針對後端的環境進行一系列的搭建。待專案開發、測試完成就直接部署，而不是等到開發、測試完成之後才來從0開始部署。
> 本文可轉載，需註明出處(公號:卡二條的技術圈)
本作品採用《CC 協議》，轉載必須註明作者和本文連結