前端
前端開發人員專註業務的頁面呈現，非常註重用戶體驗度，也是與各種角色打交道最多的。
比如：
壹般前端工作包括六個部分：
後端
如果前後端職責劃分很清楚的話，後端更多開發工作在於業務接口設計、業務邏輯處理以及數據的持久化存儲，並提供詳細的接口設計文檔給前端開發人員使用。
壹般後端工作包括五個部分：
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 異步處理；
如果壹個接口的業務容量太大，那麽業務耦合性高，萬壹需求變更，後端程序改動大，不利於程序的擴展。
壹、前後端分離的思想要轉變
不能老是按照傳統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 （大的系統組織總是比小系統更傾向於分解）
康威定律說明以下幾點
四、部署及監控運維
前後端分離後，拆分的服務會帶來線上部署以及如何監控運維的復雜性。
總體來說，前後分離所帶來的好處還是更明顯的。壹個成熟的前後端分離的團隊，文檔化約定，前後端職責分離、接口約定都是做得比較好的