作者 | 嫻靜

不管你設(shè)計的系統(tǒng)架構(gòu)是怎么樣，最后都是你的組織內(nèi)的溝通結(jié)構(gòu)勝出。這個觀點一直在組織內(nèi)不斷地被證明，但也不斷地被忽略。

前后端分離的利與弊

近幾年，隨著微服務(wù)架構(gòu)風(fēng)格的引入、前后端生態(tài)的快速發(fā)展、多端產(chǎn)品化的出現(xiàn)，前后端分離已經(jīng)成為行業(yè)的普遍實踐，也是大型企業(yè)級分布式架構(gòu)的缺省選擇。

前后端分離也給軟件技術(shù)人員的職業(yè)發(fā)展和協(xié)作方式帶來了新的變化，分別出現(xiàn)了前端工程師、后端工程師、前端開發(fā)團隊以及后端開發(fā)團隊。

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

這帶來了如下的好處：

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

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

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

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

那到底分不分呢？是什么在影響我們的架構(gòu)？

組織的溝通結(jié)構(gòu)決定軟件構(gòu)架

康威定律：設(shè)計系統(tǒng)的組織由于受到約束，這些設(shè)計往往是組織內(nèi)部溝通結(jié)構(gòu)的副本。

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

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

后面就差寫上page了??

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

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

設(shè)計團隊的溝通結(jié)構(gòu)

那么，回到最初的問題，如果作為架構(gòu)師的我們，想要實現(xiàn)前后端技術(shù)分離的分布式架構(gòu)，如何設(shè)計團隊的溝通結(jié)構(gòu)？

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

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

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

圖1.2 方案A的端到端交付團隊服務(wù)的架構(gòu)圖

圖1.1和1.2分別展示了方案A中前后端團隊如何圍繞架構(gòu)進行協(xié)作。方案A的假設(shè)在于前后端分別是不同的服務(wù)/產(chǎn)品，向不同的服務(wù)對象提供某種服務(wù)。

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

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

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

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

圖2.2 方案B的端到端團隊協(xié)作的架構(gòu)圖

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

它的好處在于，能夠完成端到端的交付，不需要依賴其它團隊，團隊自己有能力進行快速的業(yè)務(wù)創(chuàng)新和探索，也可以與領(lǐng)域子系統(tǒng)進行協(xié)作達成目的。

其缺點則在于：

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

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

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

1. 前后端并行開發(fā)，在集成時返工
2. 后端API為前端而設(shè)計，耦合度高
3. 前后端人員比例與業(yè)務(wù)的節(jié)奏和復(fù)雜度不能靈活匹配，出現(xiàn)前端等后端，或者后端等前端聯(lián)調(diào)的情況，造成浪費。

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

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

• 既要尊重現(xiàn)在的前后端技術(shù)發(fā)展趨勢和生態(tài)不同，各自有不同的關(guān)注點和特點
• 又要為達成業(yè)務(wù)目標而努力。

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

在考慮這個問題的時候，切入點依然是康威定律的指引。我們會發(fā)現(xiàn)，一個項目的架構(gòu)也并不是一成不變的，它會隨著業(yè)務(wù)的變化而變化，在產(chǎn)品的早期、成熟期、規(guī)模期，架構(gòu)是不同的形態(tài)，我們?yōu)槭裁床豢梢杂脛討B(tài)的眼光去設(shè)計我們團隊的溝通結(jié)構(gòu)呢？答案是顯然的。

所以就有如下的解法：

假設(shè)業(yè)務(wù)及技術(shù)的復(fù)雜度和規(guī)模隨著時間而增加。那么：

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

這些變化都會促成前后端團隊的逐漸分離。這個時候前后端團隊也會適當增加轉(zhuǎn)向架構(gòu)和特定領(lǐng)域的技術(shù)專家，可能增加特定領(lǐng)域團隊，而大前端的工程師則會補充前端+Bff的開發(fā)能力訴求。

總結(jié)

前后端分離本質(zhì)上是技術(shù)的分離，而不是人員的分離。團隊要不要分取決于你如何設(shè)計你的架構(gòu)，也取決于你的業(yè)務(wù)模式，所服務(wù)的產(chǎn)品形態(tài)、團隊能力、工程實踐的成熟度。

前后端團隊分離的成本是極高的，對團隊的能力要求也是極高的。它并不適合業(yè)務(wù)不明確，交付優(yōu)先級經(jīng)常變動，需要快速交付，且需要不斷創(chuàng)新和探索的業(yè)務(wù)。

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

本文的討論并不涉及Mobile app的開發(fā)。如果你的架構(gòu)既有Web端，又有Native app， 小程序，你的團隊結(jié)構(gòu)是怎么設(shè)計的呢？