作者 | 嫻靜

不管你設計的系統架構是怎么樣，最后都是你的組織內的溝通結構勝出。這個觀點一直在組織內不斷地被證明，但也不斷地被忽略。

前后端分離的利與弊

近幾年，隨著微服務架構風格的引入、前后端生態的快速發展、多端產品化的出現，前后端分離已經成為行業的普遍實踐，也是大型企業級分布式架構的缺省選擇。

前后端分離也給軟件技術人員的職業發展和協作方式帶來了新的變化，分別出現了前端工程師、后端工程師、前端開發團隊以及后端開發團隊。

前后端分離使得前端關注信息架構，處理用戶體驗相關問題；而后端則關注構建業務能力、數據處理、持久化等問題，并向前端提供API接口(API as product)，由前端進行消費。前端工程師不需要關注后端的具體實現和技術框架，后端工程師也不需要關注前端的具體實現和技術框架。

這帶來了如下的好處：

• 前后端用戶體驗和業務邏輯解耦。不同端以及不同用戶體驗的變化不再影響后端API接口。后端API聚焦在表達業務能力，可同時服務于多端產品，而無需更改。
• 后端無需考慮業務邏輯或能力升級對前端的影響，只要保證接口不變即可。
• 響應變快。對前端尤其是多端服務出現后，前后端分代碼和打包部署等技術分離、可以更快地響應不同的用戶體驗需求，而不必等待后端。
• 前后端工程師能力聚焦，可以專注各自領域的技術學習，聚焦提升自己的專項技能和經驗。
• 前后端團隊邊界明顯，認知負荷降低，單點開發效率高，只需關注本端的開發任務和技術即可。

分離帶來的好處漸漸體現出來，尤其是在一些大型的互聯網項目尤為明顯。然而也有很多前后端分離的交付團隊中出現了如下的問題：

• 團隊開發業務的大小和復雜度隨著項目的進行發生變更，引起前后端團隊人員比例失調，比如出現前端開發團隊進度快，需要等后端團隊聯調，或者反過來，后端團隊等前端的情況，開發進度不暢，溝通協作成本高。
• 這樣的臨時任務變動，不管新增還是調換人員的動態調整成本高，體驗差。
• 業務開發節奏快，沒有足夠時間量留給后端預先設計API，前端團隊只能靠自己的猜測和僅有的共識進行開發，聯調時雙方分頭再改一遍，返工高，溝通協作成本高。
• API的設計也受前端消費者和開發節奏的影響，面向前端的用戶體驗設計。
• 多個相同組件模塊間出現多種不同的做法。

那么，前后端團隊不分行不行。當然行，前后端人員不分的協作模式可以靈活匹配開發任務、全棧能力提升、同時團隊還可以了解端到端的業務；但同時也使得團隊整體的認知負荷高，架構越復雜成本越高，還會影響整體的開發效率。

那到底分不分呢？是什么在影響我們的架構？

組織的溝通結構決定軟件構架

康威定律：設計系統的組織由于受到約束，這些設計往往是組織內部溝通結構的副本。

分不分答案其實很簡單，就如文章開頭所言，不管架構怎么設計，不管作為技術從業者的我們多少次向更好地架構和技術發起努力，但還是會看到“為什么得不到想要的設計，為什么明明是一個架構卻各不相同”。因為，在這場對抗中，最后一定是組織的溝通結構勝出。實際上也確實是這樣。從上述壞味道以及這些“前后端分離團隊”的代碼中也可以看出：

• /stock-schema/customer-detail
• /stocks/createAndNext
• /stocks/query-list?

后面就差寫上page了??

前后端分離看似簡單，然而它實際上是技術的分離而非團隊的分離。如果要真正實現前后端團隊分離的協作模式，或者反過來要想實現前后端技術分離的分布式架構，都要首先考慮組織的溝通結構設計，讓它去服務于你想要的及架構。

尤其是當我們在構建和運行大規模軟件系統的時候，更需要刻意設計我們的團隊溝通結構，以促成“低摩擦”的軟件交付，避免“跨部門的職能豎井”、嚴重依賴外包資源、大量工作件流動受阻、無法提供快速交付或者難以滿足現有業務服務的組織反饋機制”。

設計團隊的溝通結構

那么，回到最初的問題，如果作為架構師的我們，想要實現前后端技術分離的分布式架構，如何設計團隊的溝通結構？

我參考《高效能團隊協作模式》中作者給出的四種拓撲類型、三種協作模式，以及設計原則試著給出如下兩種答案：

1.方案A - 前后端分離的特性交付團隊

圖1.1 方案A的端到端交付團隊協作模式

圖1.2 方案A的端到端交付團隊服務的架構圖

圖1.1和1.2分別展示了方案A中前后端團隊如何圍繞架構進行協作。方案A的假設在于前后端分別是不同的服務/產品，向不同的服務對象提供某種服務。

每個團隊都是端到端的交付團隊，好處是團隊高度重視用戶價值和服務的可用性，可以快速的響應各自的變化，團隊的認知邊界也很清晰，協作成本低，效率高。它的挑戰則在于服務的邊界是否定義良好、能否被正確實現，服務提供方可以實施服務管理實踐時，這種模式才能正常運作。一旦邊界或API不合理，效率會降低。這種方案對團隊的服務/產品設計和管理能力要求較高。

方案A中賦能團隊、以及可能的領域子系統團隊是必不可少的。尤其在團隊和業務規模增長的情況下，這兩個團隊的存在是為了補齊端到端特性團隊的能力短板，降低認知負荷，提供特定領域的支持和賦能，同時避免了因組織溝通壁壘導致的規范、實踐、重復造輪子、能力缺少等共性問題，尤其促進了跨組織的低摩擦軟件交付和特性團隊的交付效能。

2. 方案B-端到端交付團隊

圖2.1 方案B的端到端交付團隊協作模式

圖2.2 方案B的端到端團隊協作的架構圖

圖2.1和2.2分別展示了方案B中前后端團隊如何圍繞架構進行寫作。方案B同樣以端到端的特性團隊為主，它將整個架構所服務的Web系統看做是一個服務或產品。因此，采取縱向切片的方式劃分端到端的特性交付團隊。在這樣的團隊協作中，前后端技術分離但不分家，前后端工程師分別以組件開發的方式進行協作和內部集成。

它的好處在于，能夠完成端到端的交付，不需要依賴其它團隊，團隊自己有能力進行快速的業務創新和探索，也可以與領域子系統進行協作達成目的。

其缺點則在于：

1. 前后端開發集成需要較多的協作和溝通成本
2. 需要迭代計劃的配合
3. 這些開發細節和溝通等待會產生較高的認知負荷，對整體效率產生影響
4. 對團隊能力挑戰大

同樣，方案B中賦能團隊、以及可能的領域子系統團隊是必不可少的，這兩個團隊的存在避免了因組織溝通壁壘導致的規范、實踐、重復造輪子、能力缺少等共性問題，尤其促進了跨組織特性團隊的低摩擦交付和效能。

然，方案B的另一個問題在于，通常端到端交付的節奏都比較快，要預先留給后端進行設計的時間并不多，所以也會很容易出現在文章開頭的問題（又回到原點??）：

1. 前后端并行開發，在集成時返工
2. 后端API為前端而設計，耦合度高
3. 前后端人員比例與業務的節奏和復雜度不能靈活匹配，出現前端等后端，或者后端等前端聯調的情況，造成浪費。

• 根據業務變化，動態的調整前后端工程師的比例。人員協調成本高，團隊人員體驗差，成長不利。
• Web開發前后端能力全棧，Story前后端一起做，靈活匹配開發任務、團隊能力提升、還可以同時了解端到端的業務和實現；但同時也使得團隊整體的認知負荷高，前后端技術和架構越復雜成本越高，還會影響整體的開發效率；也還需要同時考慮人員的成長與發展。
• 適當增加全棧的比例，前端和后端分開做，由全棧同學做“自由人”切換前后端開發任務。自由人越多，團隊整體的適應力就越強，對自由人的挑戰和依賴較大。

在我的訪談中，1、2、3均有很多團隊嘗試過或正在采納。大多數團隊前后端的比例在1:2 ~ 1:4之間調整。訪談的同學都提到了兩個決策因素：

• 既要尊重現在的前后端技術發展趨勢和生態不同，各自有不同的關注點和特點
• 又要為達成業務目標而努力。

那么，還有其它的解法嗎？從《高效團隊協作模式》一書中我找到了另一種答案：

在考慮這個問題的時候，切入點依然是康威定律的指引。我們會發現，一個項目的架構也并不是一成不變的，它會隨著業務的變化而變化，在產品的早期、成熟期、規模期，架構是不同的形態，我們為什么不可以用動態的眼光去設計我們團隊的溝通結構呢？答案是顯然的。

所以就有如下的解法：

假設業務及技術的復雜度和規模隨著時間而增加。那么：

• 在交付初期，業務和技術的復雜度相對較低，要求業務快速上線完成價值轉化。前端后端更多的是在構建基礎的頁面和模型。與此同時，團隊剛剛形成，需要端到端的去了解業務的價值，面向Web開發的全棧更容易促成團隊的組建、規范和達成業務目標。?
• 交付中期，業務開始增長，有復雜的業務流程引入，以及用戶體驗要求上升。前后端的技術復雜度也隨之而來，比如頁面的渲染，交互操作，微前端的引入、數據的一致性，業務的可用性都開始有了較高的要求。?同時，代碼量也到了一定的量級，在耦合性、內聚性也都出現了不同程度的質量要求。這個時候，可以適當的開始引入前后端專家，以賦能角色促進的方式與全棧團隊進行協作，解決技術難度，整潔代碼治理，賦能規范和對應的前后端工程實踐等以提高整體的工程效能。
• 交付的成熟期，隨著業務規模發展，系統架構也開始變的復雜起來，用戶多了起來，除了功能特性，也會在頁面加載性能、數據安全等方面提出新的要求。與此同時，也會出現多端產品服務，開發者生態的形成也會促進后端形成平臺化的能力。?

這些變化都會促成前后端團隊的逐漸分離。這個時候前后端團隊也會適當增加轉向架構和特定領域的技術專家，可能增加特定領域團隊，而大前端的工程師則會補充前端+Bff的開發能力訴求。

總結

前后端分離本質上是技術的分離，而不是人員的分離。團隊要不要分取決于你如何設計你的架構，也取決于你的業務模式，所服務的產品形態、團隊能力、工程實踐的成熟度。

前后端團隊分離的成本是極高的，對團隊的能力要求也是極高的。它并不適合業務不明確，交付優先級經常變動，需要快速交付，且需要不斷創新和探索的業務。

從個人成長來看，前后端分不分并不重要，而是于自己的發展目標與項目機會是否匹配，團隊不應該成為我們成長的阻礙，而應該化為促進我們成長的平臺。

本文的討論并不涉及Mobile app的開發。如果你的架構既有Web端，又有Native app， 小程序，你的團隊結構是怎么設計的呢？