不管你設計的系統架構是怎麼樣，最後都是你的組織內的溝通結構勝出。這個觀點一直在組織內不斷地被證明，但也不斷地被忽略。
前後端分離的利與弊
近幾年，隨着微服務架構風格的引入、前後端生態的快速發展、多端產品化的出現，前後端分離已經成爲行業的普遍實踐，也是大型企業級分佈式架構的缺省選擇。
前後端分離也給軟件技術人員的職業發展和協作方式帶來了新的變化，分別出現了前端工程師、後端工程師、前端開發團隊以及後端開發團隊。
前後端分離使得前端關注信息架構，處理用戶體驗相關問題；而後端則關注構建業務能力、數據處理、持久化等問題，並向前端提供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系統看做是一個服務或產品。因此，採取縱向切片的方式劃分端到端的特性交付團隊。在這樣的團隊協作中，前後端技術分離但不分家，前後端工程師分別以組件開發的方式進行協作和內部集成。
它的好處在於，能夠完成端到端的交付，不需要依賴其它團隊，團隊自己有能力進行快速的業務創新和探索，也可以與領域子系統進行協作達成目的。
其缺點則在於：
- 前後端開發集成需要較多的協作和溝通成本
- 需要迭代計劃的配合
- 這些開發細節和溝通等待會產生較高的認知負荷，對整體效率產生影響
- 對團隊能力挑戰大
同樣，方案B中賦能團隊、以及可能的領域子系統團隊是必不可少的，這兩個團隊的存在避免了因組織溝通壁壘導致的規範、實踐、重複造輪子、能力缺少等共性問題，尤其促進了跨組織特性團隊的低摩擦交付和效能。
然，方案B的另一個問題在於，通常端到端交付的節奏都比較快，要預先留給後端進行設計的時間並不多，所以也會很容易出現在文章開頭的問題（又回到原點）：
- 前後端並行開發，在集成時返工
- 後端API爲前端而設計，耦合度高
- 前後端人員比例與業務的節奏和複雜度不能靈活匹配，出現前端等後端，或者後端等前端聯調的情況，造成浪費。
這些問題如何解決？
- 根據業務變化，動態的調整前後端工程師的比例。人員協調成本高，團隊人員體驗差，成長不利。
- Web開發前後端能力全棧，Story前後端一起做，靈活匹配開發任務、團隊能力提升、還可以同時瞭解端到端的業務和實現；但同時也使得團隊整體的認知負荷高，前後端技術和架構越複雜成本越高，還會影響整體的開發效率；也還需要同時考慮人員的成長與發展。
- 適當增加全棧的比例，前端和後端分開做，由全棧同學做“自由人”切換前後端開發任務。自由人越多，團隊整體的適應力就越強，對自由人的挑戰和依賴較大。
在我的訪談中，1、2、3均有很多團隊嘗試過或正在採納。大多數團隊前後端的比例在1:2 ~ 1:4之間調整。訪談的同學都提到了兩個決策因素：
- 既要尊重現在的前後端技術發展趨勢和生態不同，各自有不同的關注點和特點
- 又要爲達成業務目標而努力。
那麼，還有其它的解法嗎？從《高效團隊協作模式》一書中我找到了另一種答案：
在考慮這個問題的時候，切入點依然是康威定律的指引。我們會發現，一個項目的架構也並不是一成不變的，它會隨着業務的變化而變化，在產品的早期、成熟期、規模期，架構是不同的形態，我們爲什麼不可以用動態的眼光去設計我們團隊的溝通結構呢？答案是顯然的。
所以就有如下的解法：
假設業務及技術的複雜度和規模隨着時間而增加。那麼：
-
在交付初期，業務和技術的複雜度相對較低，要求業務快速上線完成價值轉化。
前端後端更多的是在構建基礎的頁面和模型。與此同時，團隊剛剛形成，需要端到端的去了解業務的價值，面向Web開發的全棧更容易促成團隊的組建、規範和達成業務目標。
-
交付中期，業務開始增長，有複雜的業務流程引入，以及用戶體驗要求上升。
前後端的技術複雜度也隨之而來，比如頁面的渲染，交互操作，微前端的引入、數據的一致性，業務的可用性都開始有了較高的要求。
同時，代碼量也到了一定的量級，在耦合性、內聚性也都出現了不同程度的質量要求。
這個時候，可以適當的開始引入前後端專家，以賦能角色促進的方式與全棧團隊進行協作，解決技術難度，整潔代碼治理，賦能規範和對應的前後端工程實踐等以提高整體的工程效能。 -
交付的成熟期，隨着業務規模發展，系統架構也開始變的複雜起來，用戶多了起來，除了功能特性，也會在頁面加載性能、數據安全等方面提出新的要求。
與此同時，也會出現多端產品服務，開發者生態的形成也會促進後端形成平臺化的能力。
這些變化都會促成前後端團隊的逐漸分離。
這個時候前後端團隊也會適當增加轉向架構和特定領域的技術專家，可能增加特定領域團隊，而大前端的工程師則會補充前端+Bff的開發能力訴求。
總結
前後端分離本質上是技術的分離，而不是人員的分離。團隊要不要分取決於你如何設計你的架構，也取決於你的業務模式，所服務的產品形態、團隊能力、工程實踐的成熟度。
前後端團隊分離的成本是極高的，對團隊的能力要求也是極高的。它並不適合業務不明確，交付優先級經常變動，需要快速交付，且需要不斷創新和探索的業務。
從個人成長來看，前後端分不分並不重要，而是於自己的發展目標與項目機會是否匹配，團隊不應該成爲我們成長的阻礙，而應該化爲促進我們成長的平臺。
本文的討論並不涉及Mobile app的開發。如果你的架構既有Web端，又有Native app， 小程序，你的團隊結構是怎麼設計的呢？
（感謝李源春、廖安棟、趙林、付世威等同學的輸入）
推薦閱讀
文/Thoughtworks 禚嫺靜
原文鏈接：https://insights.thoughtworks.cn/low-friction-software-delivery-teams-patterns/