。

这个观点一直在组织内不断地被证明#xff0c;但也不断地被忽略。

近几年#xff0c;随着微服务架构风格的引入、前后端生态的快速发展、多端产品化的出现#xff0c;前后…不管你设计的系统架构是怎么样最后都是你的组织内的沟通结构胜出。

这个观点一直在组织内不断地被证明但也不断地被忽略。

近几年随着微服务架构风格的引入、前后端生态的快速发展、多端产品化的出现前后端分离已经成为行业的普遍实践也是大型企业级分布式架构的缺省选择。

前后端分离也给软件技术人员的职业发展和协作方式带来了新的变化分别出现了前端工程师、后端工程师、前端开发团队以及后端开发团队。

前后端分离使得前端关注信息架构处理用户体验相关问题而后端则关注构建业务能力、数据处理、持久化等问题并向前端提供API接口(API

product)由前端进行消费。

前端工程师不需要关注后端的具体实现和技术框架后端工程师也不需要关注前端的具体实现和技术框架。

前后端用户体验和业务逻辑解耦。

不同端以及不同用户体验的变化不再影响后端API接口。

后端API聚焦在表达业务能力可同时服务于多端产品而无需更改。

后端无需考虑业务逻辑或能力升级对前端的影响只要保证接口不变即可。

响应变快。

对前端尤其是多端服务出现后前后端分代码和打包部署等技术分离、可以更快地响应不同的用户体验需求而不必等待后端。

前后端工程师能力聚焦可以专注各自领域的技术学习聚焦提升自己的专项技能和经验。

前后端团队边界明显认知负荷降低单点开发效率高只需关注本端的开发任务和技术即可。

分离带来的好处渐渐体现出来尤其是在一些大型的互联网项目尤为明显。

然而也有很多前后端分离的交付团队中出现了如下的问题

团队开发业务的大小和复杂度随着项目的进行发生变更引起前后端团队人员比例失调比如出现前端开发团队进度快需要等后端团队联调或者反过来后端团队等前端的情况开发进度不畅沟通协作成本高。

这样的临时任务变动不管新增还是调换人员的动态调整成本高体验差。

业务开发节奏快没有足够时间量留给后端预先设计API前端团队只能靠自己的猜测和仅有的共识进行开发联调时双方分头再改一遍返工高沟通协作成本高。

API的设计也受前端消费者和开发节奏的影响面向前端的用户体验设计。

多个相同组件模块间出现多种不同的做法。

那么前后端团队不分行不行。

当然行前后端人员不分的协作模式可以灵活匹配开发任务、全栈能力提升、同时团队还可以了解端到端的业务但同时也使得团队整体的认知负荷高架构越复杂成本越高还会影响整体的开发效率。

康威定律设计系统的组织由于受到约束这些设计往往是组织内部沟通结构的副本。

分不分答案其实很简单就如文章开头所言不管架构怎么设计不管作为技术从业者的我们多少次向更好地架构和技术发起努力但还是会看到“为什么得不到想要的设计为什么明明是一个架构却各不相同”。

因为在这场对抗中最后一定是组织的沟通结构胜出。

实际上也确实是这样。

从上述坏味道以及这些“前后端分离团队”的代码中也可以看出

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

前后端分离看似简单然而它实际上是技术的分离而非团队的分离。

如果要真正实现前后端团队分离的协作模式或者反过来要想实现前后端技术分离的分布式架构都要首先考虑组织的沟通结构设计让它去服务于你想要的及架构。

尤其是当我们在构建和运行大规模软件系统的时候更需要刻意设计我们的团队沟通结构以促成“低摩擦”的软件交付避免“跨部门的职能竖井”、严重依赖外包资源、大量工作件流动受阻、无法提供快速交付或者难以满足现有业务服务的组织反馈机制”。

那么回到最初的问题如果作为架构师的我们想要实现前后端技术分离的分布式架构如何设计团队的沟通结构

我参考《高效能团队协作模式》中作者给出的四种拓扑类型、三种协作模式以及设计原则试着给出如下两种答案

1.方案A

图1.1和1.2分别展示了方案A中前后端团队如何围绕架构进行协作。

方案A的假设在于前后端分别是不同的服务/产品向不同的服务对象提供某种服务。

每个团队都是端到端的交付团队好处是团队高度重视用户价值和服务的可用性可以快速的响应各自的变化团队的认知边界也很清晰协作成本低效率高。

它的挑战则在于服务的边界是否定义良好、能否被正确实现服务提供方可以实施服务管理实践时这种模式才能正常运作。

一旦边界或API不合理效率会降低。

这种方案对团队的服务/产品设计和管理能力要求较高。

方案A中赋能团队、以及可能的领域子系统团队是必不可少的。

尤其在团队和业务规模增长的情况下这两个团队的存在是为了补齐端到端特性团队的能力短板降低认知负荷提供特定领域的支持和赋能同时避免了因组织沟通壁垒导致的规范、实践、重复造轮子、能力缺少等共性问题尤其促进了跨组织的低摩擦软件交付和特性团队的交付效能。

方案B-端到端交付团队

图2.1和2.2分别展示了方案B中前后端团队如何围绕架构进行写作。

方案B同样以端到端的特性团队为主它将整个架构所服务的Web系统看做是一个服务或产品。

因此采取纵向切片的方式划分端到端的特性交付团队。

在这样的团队协作中前后端技术分离但不分家前后端工程师分别以组件开发的方式进行协作和内部集成。

它的好处在于能够完成端到端的交付不需要依赖其它团队团队自己有能力进行快速的业务创新和探索也可以与领域子系统进行协作达成目的。

其缺点则在于

前后端开发集成需要较多的协作和沟通成本需要迭代计划的配合这些开发细节和沟通等待会产生较高的认知负荷对整体效率产生影响对团队能力挑战大

同样方案B中赋能团队、以及可能的领域子系统团队是必不可少的这两个团队的存在避免了因组织沟通壁垒导致的规范、实践、重复造轮子、能力缺少等共性问题尤其促进了跨组织特性团队的低摩擦交付和效能。

然方案B的另一个问题在于通常端到端交付的节奏都比较快要预先留给后端进行设计的时间并不多所以也会很容易出现在文章开头的问题又回到原点

前后端并行开发在集成时返工后端API为前端而设计耦合度高前后端人员比例与业务的节奏和复杂度不能灵活匹配出现前端等后端或者后端等前端联调的情况造成浪费。

这些问题如何解决

根据业务变化动态的调整前后端工程师的比例。

人员协调成本高团队人员体验差成长不利。

Web开发前后端能力全栈Story前后端一起做灵活匹配开发任务、团队能力提升、还可以同时了解端到端的业务和实现但同时也使得团队整体的认知负荷高前后端技术和架构越复杂成本越高还会影响整体的开发效率也还需要同时考虑人员的成长与发展。

适当增加全栈的比例前端和后端分开做由全栈同学做“自由人”切换前后端开发任务。

自由人越多团队整体的适应力就越强对自由人的挑战和依赖较大。

在我的访谈中1、2、3均有很多团队尝试过或正在采纳。

大多数团队前后端的比例在1:2

既要尊重现在的前后端技术发展趋势和生态不同各自有不同的关注点和特点又要为达成业务目标而努力。

那么还有其它的解法吗从《高效团队协作模式》一书中我找到了另一种答案

在考虑这个问题的时候切入点依然是康威定律的指引。

我们会发现一个项目的架构也并不是一成不变的它会随着业务的变化而变化在产品的早期、成熟期、规模期架构是不同的形态我们为什么不可以用动态的眼光去设计我们团队的沟通结构呢答案是显然的。

在交付初期业务和技术的复杂度相对较低要求业务快速上线完成价值转化。

前端后端更多的是在构建基础的页面和模型。

与此同时团队刚刚形成需要端到端的去了解业务的价值面向Web开发的全栈更容易促成团队的组建、规范和达成业务目标。

交付中期业务开始增长有复杂的业务流程引入以及用户体验要求上升。

前后端的技术复杂度也随之而来比如页面的渲染交互操作微前端的引入、数据的一致性业务的可用性都开始有了较高的要求。

同时代码量也到了一定的量级在耦合性、内聚性也都出现了不同程度的质量要求。

这个时候可以适当的开始引入前后端专家以赋能角色促进的方式与全栈团队进行协作解决技术难度整洁代码治理赋能规范和对应的前后端工程实践等以提高整体的工程效能。

交付的成熟期随着业务规模发展系统架构也开始变的复杂起来用户多了起来除了功能特性也会在页面加载性能、数据安全等方面提出新的要求。

与此同时也会出现多端产品服务开发者生态的形成也会促进后端形成平台化的能力。

这些变化都会促成前后端团队的逐渐分离。

这个时候前后端团队也会适当增加转向架构和特定领域的技术专家可能增加特定领域团队而大前端的工程师则会补充前端Bff的开发能力诉求。

前后端分离本质上是技术的分离而不是人员的分离。

团队要不要分取决于你如何设计你的架构也取决于你的业务模式所服务的产品形态、团队能力、工程实践的成熟度。

前后端团队分离的成本是极高的对团队的能力要求也是极高的。

它并不适合业务不明确交付优先级经常变动需要快速交付且需要不断创新和探索的业务。

从个人成长来看前后端分不分并不重要而是于自己的发展目标与项目机会是否匹配团队不应该成为我们成长的阻碍而应该化为促进我们成长的平台。

app