一、職責劃分
前端
前端工作專注業務的頁面呈現，非常注重用戶體驗度，也是與各種角色打交道最多的。
比如：
-
前端開發人員會經常與產品經理或者客戶討論頁面樣式、視覺效果，頁面佈局等各種頁面渲染效果
-
前端開發人員要與UI設計師對接：字體大小、顏色、頁面佈局、樣式等
-
前端開發人員與多個後端開發人員接口對接
-
前端開發人員與測試人員基於bug修復討論
一般前端工作包括六個部分：
1、UI設計師與產品經理對接需求
2、UI設計：UI設計師設計高保真圖，給前端開發人員設計真實頁面
3、頁面開發：根據UI設計師提供的高保真圖，進行頁面模塊開發
4、前後端接口對接：與後端開發人員對接API接口
5、前後端聯調測試：包括頁面展示以及接口數據
6、bug修復
後端
如果前後端職責劃分很清楚的話，後端更多開發工作在於業務接口設計、業務邏輯處理以及數據的持久化存儲，並提供詳細的接口設計文檔給前端開發人員使用。
一般後端工作包括五個部分：
1、與產品經理對接需求
2、業務API接口開發：根據根據需求文檔進行業務接口開發
4、接口對接：與前端開發人員接口對接
5、前後端聯調測試：包括頁面展示以及接口數據
6、bug修復
二、技術劃分
前端開發技術棧
h5、css、nodejs/vue/angular/react、webpack、hbuilder/vscode等
後端開發技術棧
後端更注重業務邏輯處理，以數據爲中心，關注數據存儲及高併發請求等。
SpringCloud/Springboot、SpringMVC、ORM框架、數據庫、緩存框架（Redis，Codis\Memcached等），大數據框架（Hadoop/Spark/hive/Hbase/Storm/ES/Kafka等）等等
三、我們約定
技術選型
最好選擇成熟穩定，易上手、開發效率高的技術，因爲實際項目開發時間是有限的，開發人員沒有多少精力放在學習和深度研究技術上。
數據格式
後端開發提供接口設計文檔，詳細寫明每個接口的請求地址、請求參數、響應參數等等；一般採用REST風格以JSON格式提供數據。
接口設計
一個接口設計的好壞，直接影響到前後端一些溝通協調問題。
依筆者經驗來看，如果後端接口不穩定，會導致前端開發人員反覆修改頁面數據呈現。常常出現後端開發說這是前端問題，前端開發說是後端問題，來回扯皮，溝通效率低下。
從前端開發的角度來說，他們更關注用戶體驗效果， 因爲客戶看到的是最終頁面，頁面效果以及數據呈現效果的好壞最能反映客戶的滿意度的。客戶不關注你用了什麼牛逼的技術，有什麼牛逼的人。
從後端開發角度來說，他們更關注程序的可靠性、穩定性、安全性以及是數據完整性、一致性等。
所以前後端雙方關注點不同，難免會涉及到一些工作量大小問題。例如接口粒度問題
接口容量問題
一個接口的業務容量大小，往往代表前後端工作量的大小。
如果一個接口的業務容量太小，前端需要分階段處理的事情就多，尤其是對多個接口Ajax異步處理；如果一個接口的業務容量太大，那麼業務耦合性高，萬一需求變更，後端程序改動大，不利於程序的擴展。
四、分離帶來的優勢
-
前後端職責分明，分工明細
-
局部變化，不會影響所有業務功能；也不會因爲某局部功能修改，而導致所有程序重啓服務。
-
開發效率高，在不涉及接口聯調時，前後端互不干擾
-
聯調簡單，前後端保證API接口規範穩定就行
-
問題責任清晰，聯調/測試/預發/上線/bug，都能馬上定位是哪方的問題。
-
自動化部署：容器化部署：docker+k8s
五、分離帶來的問題
一、前後端分離思想要轉變
不能老是按照傳統WEB（js/h5/css/後端代碼放在一個工程）開發思維去看待前後端分離
二、溝通成本問題
以前傳統WEB開發，開發人員從需求到設計到開發基本上是一個人。而前後端分離後，前端只負責頁面呈現，後端更注重業務邏輯處理以及數據的持久化，雙發都有自己的側重點，工作量上有私心。
三、組織結構問題
康威定律
第一定律：Communication dictates design（組織溝通方式會通過系統設計表達出來）
第二定律：There is never enough time to do something right, but there is always enough time to do it over（時間再多一件事情也不可能做的完美，但總有時間做完一件事情）
第三定律：There is a homomorphism from the linear graph of a system to the linear graph of its design organization（線型系統和線型組織架構間有潛在的異質同態特性）
第四定律： The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems（大的系統組織總是比小系統更傾向於分解）
康威定律說明以下幾點
-
人與人的溝通是非常複雜的，一個人的溝通精力是有限的，所以當問題太複雜需要很多人解決的時候，我們需要做拆分組織來達成對溝通效率的管理
-
組織內人與人的溝通方式決定了他們參與的系統設計，管理者可以通過不同的拆分方式帶來不同的團隊間溝通方式，從而影響系統設計
-
如果子系統是內聚的，和外部的溝通邊界是明確的，能降低溝通成本，對應的設計也會更合理高效
-
複雜的系統需要通過容錯彈性的方式持續優化，不要指望一個大而全的設計或架構，好的架構和設計都是慢慢迭代出來的
四、部署及監控運維
前後端分離後，拆分的服務會帶來線上部署以及如何監控運維的複雜性。
六、總結
總體來說，前後分離所帶來的好處還是更明顯的。一個成熟的前後端分離的團隊，文檔化約定，前後端職責分離、接口約定都是做的比較好的