前后端分離已經是老生常談的話題了，甚至再談前后端分離顯得比較落伍。之所以想談談前后端分離，是因為在這種分工模式下實實在在的遇到了一些問題。這篇文章希望對前后端分離做一個簡單的梳理。
盡管前后端的分離已經不再新穎，但仍然有很大一部分企業由於歷史的原因，采用的是“傳統”的Web開發模式，即前端人員根據UI做好HTML頁面，再將HTML頁面交給后端開發人員打通數據和調試。這是最為“原始”的方式，甚至有可能在如今的大學課堂中仍然是這樣的教學方式。我想前端開發人員被“鄙視”也即是這樣的開發模式所導致，因為前端幾乎不做任何的調試，可能只是調整下頁面的一些工作。這樣的開發模式也很簡單，看起來是對后端開發人員要求更高，也就是要求后端開發人員掌握一定的前端基礎。
但隨着前端的發展，一些年輕的公司或者年輕的項目也早已對前后端分離進行了實踐，前端不再只寫HTML頁面，后端也不需要掌握前端JavaScript基礎。因為在前后端分離的開發模式下，前端和后端被實實在在的所隔離，后端代碼中不再將前端代碼寫到工程中，前端和后端只專注自己的領域，這樣的開發模式但也帶來了很多的問題。
后端開發人員不再參與到前端的開發，測試變得更加的抽象
以前后端開發人員寫完一個功能，只需要啟動程序，打開頁面就能自測，這是一個很具體的也很容易的一個操作。但是在分離過后，前后端代碼隔離獨立部署，后端開發人員在開發過程中不能再依靠頁面去點擊測試，唯一的方式只能加大單元測試力度。盡管每個開發者都知道單元測試的重要性，但我相信這又恰恰大多數開發者都不重視。
文檔的重要性變得更加重要
一個人寫代碼可以不需要文檔，因為我知道我要怎么做，我也知道我要怎么變。但一個系統的開發者不再是你一個人，恰好是需要和另外一個人合作的時候，這時候文檔就變成了前后端開發者的“契約”。既然是契約，那契約的制定需要變得更加謹慎，一個經常變動的契約會逐漸失去對它的信任。曾經數據的傳輸與交互是由后端一手制定，並且是“心中有數”，但前后端分離后，前端需要知道后端的數據格式，后端需要知道前端需要什么。這實際上是對后端開發人員提出了更高的要求，一是一份完善且詳盡的文檔，二是盡可能的考慮周全。
前后端的沖突可能加大
舉一個很簡單的例子，一個頁面往往由多個模塊構成，后端開發者返回的數據中只包含了某個數據的主鍵ID，前端開發者一個頁面甚至一個功能需要多次請求才能拿到數據。我相信前端開發者更希望返回的是我需要的所有數據，而后端開發者又想把這個事交給前端去做。
在這里引入一個概念：Bandend for Frontend，BFF，服務於前端的后端。如果前端分離后，前端所做的工作僅僅是數據的一些展示和少量的一些業務邏輯，我認為這個時候數據的整合業務的邏輯應該是交給后端去做，特別是如果是微服務的應用，后端應該是各個微服務的聚合，再將聚合的數據一並交給前端。但仍然有另外一個場景，前端不僅是用某個框架做了數據的展示，還使用了Node做服務端，此時我認為后端就不再去做數據的聚合，甚至可以說直接去掉后端，再換句話說此時Node也就是后端，只是時代變了，前端的開發人員取代了后端開發人員。
