作者 | 禚嫻靜

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

前后端分離的利與弊

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

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

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

這帶來(lái)了如下的好處：

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

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

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

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

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

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

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

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

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

后面就差寫上page了！

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

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

設(shè)計(jì)團(tuán)隊(duì)的溝通結(jié)構(gòu)

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

我參考《高效能團(tuán)隊(duì)協(xié)作模式》中作者給出的四種拓?fù)漕愋?、三種協(xié)作模式，以及設(shè)計(jì)原則試著給出如下兩種答案：

1.方案A - 前后端分離的特性交付團(tuán)隊(duì)

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

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

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

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

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

2 方案B-端到端交付團(tuán)隊(duì)

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

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

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

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

其缺點(diǎn)則在于：

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

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

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

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

這些問(wèn)題如何解決？

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

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

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

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

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

所以就有如下的解法：

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

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

總結(jié)

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

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

從個(gè)人成長(zhǎng)來(lái)看，前后端分不分并不重要，而是于自己的發(fā)展目標(biāo)與項(xiàng)目機(jī)會(huì)是否匹配，團(tuán)隊(duì)不應(yīng)該成為我們成長(zhǎng)的阻礙，而應(yīng)該化為促進(jìn)我們成長(zhǎng)的平臺(tái)。

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