前後端分離對於開發人員的挑戰

前後端分離已經是老生常談的話題了，甚至再談前後端分離顯得比較落伍。之所以想談談前後端分離，是因為在這種分工模式下實實在在的遇到了一些問題。這篇文章希望對前後端分離做一個簡單的梳理。

儘管前後端的分離已經不再新穎，但仍然有很大一部分企業由於歷史的原因，採用的是“傳統”的Web開發模式，即前端人員根據UI做好HTML頁面，再將HTML頁面交給後端開發人員打通數據和調試。這是最為“原始”的方式，甚至有可能在如今的大學課堂中仍然是這樣的教學方式。我想前端開發人員被“鄙視”也即是這樣的開發模式所導致，因為前端幾乎不做任何的調試，可能只是調整下頁面的一些工作。這樣的開發模式也很簡單，看起來是對後端開發人員要求更高，也就是要求後端開發人員掌握一定的前端基礎。

但隨著前端的發展，一些年輕的公司或者年輕的項目也早已對前後端分離進行了實踐，前端不再只寫HTML頁面，後端也不需要掌握前端JavaScript基礎。因為在前後端分離的開發模式下，前端和後端被實實在在的所隔離，後端代碼中不再將前端代碼寫到工程中，前端和後端只專註自己的領域，這樣的開發模式但也帶來了很多的問題。

後端開發人員不再參與到前端的開發，測試變得更加的抽象

以前後端開發人員寫完一個功能，只需要啟動程式，打開頁面就能自測，這是一個很具體的也很容易的一個操作。但是在分離過後，前後端代碼隔離獨立部署，後端開發人員在開發過程中不能再依靠頁面去點擊測試，唯一的方式只能加大單元測試力度。儘管每個開發者都知道單元測試的重要性，但我相信這又恰恰大多數開發者都不重視。

文檔的重要性變得更加重要

一個人寫代碼可以不需要文檔，因為我知道我要怎麼做，我也知道我要怎麼變。但一個系統的開發者不再是你一個人，恰好是需要和另外一個人合作的時候，這時候文檔就變成了前後端開發者的“契約”。既然是契約，那契約的制定需要變得更加謹慎，一個經常變動的契約會逐漸失去對它的信任。曾經數據的傳輸與交互是由後端一手制定，並且是“心中有數”，但前後端分離後，前端需要知道後端的數據格式，後端需要知道前端需要什麼。這實際上是對後端開發人員提出了更高的要求，一是一份完善且詳盡的文檔，二是儘可能的考慮周全。

前後端的衝突可能加大

舉一個很簡單的例子，一個頁面往往由多個模塊構成，後端開發者返回的數據中只包含了某個數據的主鍵ID，前端開發者一個頁面甚至一個功能需要多次請求才能拿到數據。我相信前端開發者更希望返回的是我需要的所有數據，而後端開發者又想把這個事交給前端去做。

在這裡引入一個概念：Bandend for Frontend，BFF，服務於前端的後端。如果前端分離後，前端所做的工作僅僅是數據的一些展示和少量的一些業務邏輯，我認為這個時候數據的整合業務的邏輯應該是交給後端去做，特別是如果是微服務的應用，後端應該是各個微服務的聚合，再將聚合的數據一併交給前端。但仍然有另外一個場景，前端不僅是用某個框架做了數據的展示，還使用了Node做服務端，此時我認為後端就不再去做數據的聚合，甚至可以說直接去掉後端，再換句話說此時Node也就是後端，只是時代變了，前端的開發人員取代了後端開發人員。