前后端分離該如何做? 這個問題，不同的技術人員，由于所處的崗位不一樣，給出的答案都不一樣。

前后端分離的問題，不僅僅是技術上的選型問題，還涉及到整個團隊在認知、職責、流程上面重新定義的問題，這也是為什么前后端分離概念看起來簡單易懂，但真正團隊在落地的時候，一不小心，往往雞飛狗跳，甚至最終放棄"治療"。

下面，基于自己之前的對一個團隊前后端分離改造的實踐經歷，介紹一下如何打造一個前后端分離的技術團隊。

背景介紹

項目介紹

交付一個服務于跨境電商的供應鏈金融項目。 需求已經相對明確，產品的原型已經出來，大概有 60 多個 Web 端的企業內部信息化的頁面，以平均 1 個頁面 2。5 個接口來計算，整個工程差不多有 150 個接口。

項目的交付需求還包括技術使用前后端分離和微服務架構。

項目交付的時間需求一共是一個半月，大概 7 周的時間。

團隊介紹

項目團隊一共 8 個后端開發，4 個前端，2 個 QA，2 個產品，團隊是從其它團隊中，各自抽調出來的，之前都沒有配合過。

團隊的技術棧是傳統的 SpringMVC + JSP + JQuery，團隊成員對前后端分離的概念都只是聽說，并沒有任何實操的經歷。

項目啟動

古語云: 兵馬未動，糧草先行。

1. 統一認識

任何技術團隊都是有慣性的，新的變化 (包括新技術，新的業務，新的開發模式等) 在團隊中的'落地生根'一般都有一個緩慢的適應過程。

而碰到這種時間緊、任務重的項目，不僅短期內需要引入這么多新的知識，并且還要求快速出成果，團隊成員里，眼里都是各種各樣的困難，從而影響到技術人員的心理狀態，產生各種消極的，甚至排斥的想法。

所以，項目啟動的時候，如何統一認識，快速讓整個團隊進入工作狀態，是最重要的問題。

2. 劃分邊界，確定流程

從本質上來說，前后端分離，相對于前后端混合團隊的最大差別就在于，團隊內部的分工顆粒度更細。 或者也可以稱為更加地解耦，從而讓各個小團隊在工作中更加地專注并且高效。

然后，解決分工的問題，相應也要引出協作的問題。把分工顆粒度切細了，邊界劃分清楚了，相應地也需要定義清楚各個小團隊如何去高效協作，這樣才能保證即高效，也不會相互干擾。

所以，前后端分離的第一步，也是最關鍵的一步，就是梳理清楚開發流程，及相應的角色職責。

角色職責

?

前端團隊

負責頁面展現的接口設計，功能頁面的開發。 并最終提交給 QA 做功能測試

?

后端團隊

負責后端的功能模塊實現，根據前端定義的接口實現對外接口；

?

測試團隊

負責銜接前端和后端團隊

開發流程

如上圖所示，里面定義出了三個團隊在前后端分離的流程中，各自的工作內容。 其中最需要關注的就在于中間各個團隊相互銜接的流程。

提交接口測試

后端團隊 -> 測試團隊。

后端團隊按功能模塊開發完接口，提交給測試團隊進行集成接口測試

后端接口對接

測試團隊 -> 前端團隊

測試團隊驗收完接口后，可以移交給前端團隊進行頁面級別的接口接入。

提交功能測試

前端團隊 -> 測試團隊

前端團隊完成了產品的包括頁面及接口上對接的工作后，就可以提交給測試團隊進行最終的功能頁面驗收了。

過程性文檔

開發流程中，每一個核心的環節，特別是涉及到多方分工協作的環節，都需要有指定的文檔輸出及相應的評審。

前后端分離中，其中比較重要的過程性文檔有如下四個：

接口契約文檔

用于定義前端與后端之間的接口定義

?

責任方: 前端團隊

第一個版本的接口契約定義，一定是前端團隊出的。 是的，你沒有看錯，后端團隊并不適合出接口的定義，因為前端團隊的思維方式是 基于頁面交互 來考慮的，后端團隊的思維方式是 基于結構化實體 來考慮的。

?

評審方：后端團隊，測試 QA，產品經理

集成測試用例文檔

用于定義驗收接口的用例

?

責任方: 測試 QA 團隊

?

評審方: 后端團隊，產品經理

功能測試用例文檔

用于定義驗收頁面功能的用例

?

評審方: 前端團隊，產品經理

?

責任方: 測試 QA 團隊

單元測試用例文檔

用于定義后端各個功能模塊的單元用例

?

評審方: 后端團隊，產品經理

?

責任方: 后端團隊

3. 技術框架

前后端分離，技術團隊的框架選型也是需要重點考慮的，一般這個職責都是各端開發的技術負責人來組織調研，并確定最終的框架。

技術框架的選型方式

編程語言

不同團隊的編程語言基礎技術棧都不一樣，比如有些團隊熟悉 PHP，有些團隊甚至基于 GO 等，更多的核心考量點還是在于，團隊成員接受度高，編程語言生態活躍度這幾個維度。

框架選型

編程語言之上的各種框架選型，如網絡框架，數據庫框架等，更多的還是基于技術負責人的架構經驗來進行選型。 只要記住一個原則：沒有通用的框架，只有合適的框架。

我們團隊最終的框架選型：

前端框架

?

編程語言：ECMA + React

React，Angular，Vue 都是優秀的前端框架，選擇上更偏向于 Github 上面的生態中，React 是 最活躍，關注度最大 的層面上來考量的。

?

開發框架：DVA + Ant-design

阿里開源的基于 React 的框架的封裝，其中有一個示例性的 demo 工程 antd-admin，可以在團隊剛起步的時候，快速進入開發流程。

后端框架

?

編程語言：Java 8

后端開發是 Java 團隊，不過建議使用 Java8 之前先做 Java 8 的培訓，特別是 Lambda，Optinal 相關使用方法，應用場景相關的新特性培訓。

?

開發框架：SpringBoot

一個好像不需要過多解釋的框架。

集成測試框架

如果團隊中的測試 QA 尚不俱備技術開發能力，建議使用 Postman 來進行集成接口測試

?

編程語言：Python

?

測試開發最方便的編程語言

?

開發框架：Pytest

?

測試用例框架

項目管理

到這里，準備工作基本就結束了。下面，你需要對整個項目的流程進行規定。

1. 定義 0.1 的里程碑

所有技術框架都只是調研的，所有流程都只是浮于表面的。

項目開工的第一個核心任務就是討論出最小的工程子集，目標是可以跑通所有的流程及相應的技術框架。

整個團隊形成一個共識，然后啟動開發。 從 0 到 0.1 的過程中，會碰到大量的問題，這些問題只要不阻塞開發流程的推進，即使處理得磕磕碰碰的，都可以暫時放一邊。 比如說文檔的格式如何寫，代碼的風格之類的。

當 0.1 的里程碑完成后，整個團隊會對前后端分離，不管是流程上，還是技術上，都會有一個基本的認識，并且，會有一定的成就感。 這也代表前后端分離已經有了一個好的開端了。

2. 前后端進度分離

當團隊熟悉前后端分離的流程后，前端團隊和后端團隊的進度就可以考慮徹底分開了。

前端團隊的進度

可以基于 Mock 接口的方式，分成三個階段：

2

按頁面劃分，快速出所有的頁面

只考慮量，不考慮質，以基本跑通所有的 Mock 接口為標準。

這里更多的考慮在于，前端接觸新的框架，會積累很多問題，包括 CSS 之類的，包括接口調用之類的，這些問題都有共通性，可以在下一次迭代的時候，總結出問題，分不同的人去解決。

4

基于所有的頁面進行迭代

劃分不同的人去解決團隊積累下來的問題，并統一修復。可以嘗試抽出一些共性的組件。

6

分批接入后端的模塊接口

到這個階段的時候，后端的接口理論上 QA 根據模塊，已經驗收了一部分了，可以開始分批接入，并最終提交給 QA 進行功能上的測試。

后端團隊的進度

按模塊切分開發，接口分批提交驗收。

后端可以基于業務來切分子模塊，然后，各個模塊并行開發。 接口實現后，由 QA 去進行集成用例的驗收。

測試團隊的工作內容

QA 在前后端分離流程，扮演著足球'中場'的角色，這個角色把前端團隊這個'前場'和后端團隊這個'后場'，串聯起來，承上啟下，讓他們可以各司其職，降低相互之間的耦合性。

核心工作就三個部分：

8

分批次驗收后端的模塊接口

在沒有頁面的前提下，使用工具，參考集成測試用例，對接口的健壯性，可靠性進行詳細驗證，保證在前端頁面開始接入接口的時候，接口是穩定可靠的。

10

分批次驗收前端的功能頁面

基于功能測試用例，進行頁面級別上的功能回歸

12

整合前后端的 BUG 信息

前后端的 BUG 信息全部是反饋給 QA，由 QA 統一去追相應的技術人員。 比如說前端發現有個接口有問題，只反饋給 QA，剩下的工作就是由 QA 去找相應的后端負責人。

從 1 到 N 的迭代

在這個過程中，團隊需要的是耐心及專注。

團隊的技術成長都是有節奏的，是沒有辦法一步到位的。

作為項目或者技術負責人，在這個時候，要有相對寬容的心態是看待這個問題。

隨著項目一次次迭代，會引出一個個問題，比如說，如何更加有效地寫單元測試用例，如何 更加 有效的提高頁面的渲染效率，如何讓頁面的組件 更加 的通用化。

請注意"更加"這個詞，團隊在不斷解決"更加"的問題過程中，也是不斷成長的過程。

最終，整個技術團隊會演化成一個高效分工，專注各自領域的前后端分離的快速開發的團隊。