作者|居文静无论你设计什么样的系统架构，最终获胜的还是你组织内部的沟通结构。这个观点在组织中被反复证明，但也不断被忽视。前后端分离的优缺点近年来，随着微服务架构风格的引入，前后端生态的快速发展，以及多端产品的出现，前端-端后端分离已经成为业界通行做法，也是大规模的企业级分布式架构。的默认选择。前后端分离也给软件技术人员的职业发展和协作方式带来了新的变化。分别涌现出前端工程师、后端工程师、前端开发团队、后端开发团队。前后端分离，让前端专注于信息架构，处理与用户体验相关的问题；而后端侧重于构建业务能力、数据处理、持久化等，向前端提供API接口（API即产品），供前端消费。前端工程师不需要关注后端的具体实现和技术框架，后端工程师也不需要关注前端的具体实现和技术框架。这带来了以下好处：前后端用户体验和业务逻辑解耦。不同端和不同用户体验的变化不再影响后端API接口。后端API侧重于表达业务能力，可以同时服务于多个产品，无需改动。后端无需考虑业务逻辑或能力升级对前端的影响，只要接口不变即可。响应变得更快。对于前端，尤其是多端服务出现后，前后端代码分离和打包部署技术分离，可以更快的响应不同的用户体验需求，无需等待后端-结尾。前端和后端工程师以能力为主，可以专注于各自领域的技术学习，专注于提升自己的专项技能和经验。前后端团队边界清晰，减少认知负担，单点开发效率高。只需要关注本端的开发任务和技术。分离的好处逐渐体现出来，尤其是在一些大型的互联网项目中。但是，也有很多交付团队是前后端分离的。出现以下问题：团队开发业务的规模和复杂度随着项目的推进而变化，导致前后端团队比例失衡。后端团队联调，或反之，后端团队等前端情况，开发进度不顺利，沟通协作成本高。这种临时性的任务变更，无论是增减人员的动态调整，成本高，体验差。业务发展节奏快，留给后台预先设计API的时间不够。前端团队只能靠自己的猜测和共识进行开发。联调时，双方分别进行变更，返工率高，沟通协作成本高。API的设计也受到前端消费者和开发节奏的影响，是面向前端用户体验设计的。同一组件的多个模块之间有许多不同的方法。所以，前后端团队不分开是行不通的。当然，前后端人员不分的协作模式，可以灵活匹配开发任务，提升全栈能力，团队也可以了解端到端的业务；但同时也使得团队整体的认知负荷偏高，架构越复杂，成本越高，也会影响整体的开发效率。那么到底要不要区分呢？什么在影响我们的架构？组织的通信结构决定了软件架构。康威定律：设计系统的组织是受约束的，而那些设计往往是组织内部通信结构的副本。会不会，其实答案很简单，就像文章开头提到的，无论架构如何设计，无论我们作为技术从业者为更好的架构和技术付出了多少次努力，我们仍然会看到“为什么我们不能得到我们想要的吗？”最重要的设计，为什么明明是结构却不同。”因为，在这场交锋中，组织的沟通结构最终必胜。确实如此。从上述臭味和这些“前后端分离团队”的代码也可以看出：/stock-schema/customer-detail/stocks/createAndNext/stocks/query-list?这只是写页面的问题！前后端分离看似简单，其实是技术分离而不是团队分离。如果要真正实现前后端团队分离的协作模型，或者反过来，如果要实现前后端技术分离的分布式架构，首先要考虑设计组织的沟通结构，让它为你想要的和架构服务。特别是当我们在构建和运行大型软件系统时，我们需要刻意设计我们的团队沟通结构，以促进“低摩擦”的软件交付，避免“跨部门职能孤岛”、严重依赖外包资源和工件流转阻塞，无法提供快速交付，或者难以满足现有业务服务的组织反馈机制”。设计团队的沟通结构那么，回到最初的问题，如果我们作为架构师，想要实现前后端技术分布式架构，如何设计团队的沟通结构？我参考《高效能团队协作模式》中作者给出的四种拓扑类型、三种协作模式和设计原则，尝试给出如下两个答案：1.方案A——前后端分离的特性交付团队图1.1场景A的端到端交付团队协作模式图1.2架构d场景A中端到端交付团队服务的图表图1.1和1.2显示了场景A中的前端和后端团队如何围绕架构进行协作。方案A的假设是前后端是不同的服务/产品，分别为不同的服务对象提供一定的服务。每个团队都是一个端到端的交付团队。优点是团队非常重视用户价值和服务可用性，能够快速响应自己的变化，团队的认知边界也很清晰，协作成本低，效率高。挑战在于服务的边界是否定义明确并正确实施，服务提供商是否可以实施服务管理实践以使该模型正常工作。一旦边界或API不合理，效率就会下降。该方案对团队的服务/产品设计和管理能力有更高的要求。在选项A中，支持团队和可能的域子系统团队是必不可少的。尤其是当团队和业务规模增长时，这两个团队的存在是为了弥补端到端特性团队的短板，减少认知负荷，在特定领域提供支持和赋能，避免组织差异。沟通障碍导致的规范、实践、重复造轮子、能力不足等常见问题，尤其促进了跨组织的低摩擦软件交付和特性团队的交付效率。2场景B-端到端交付团队图2.1场景B端到端交付团队协作模式图2.2场景B端到端团队协作架构图图2.1和2.2分别展示了前端如何-场景B端和后端团队轮流写。PlanB还侧重于端到端的特性团队，将整个架构所服务的Web系统视为一种服务或产品。因此，采用垂直切片的方式来划分端到端的特性交付团队。在这样的团队合作中，前后端技术分离而不分离，前后端工程师以组件化开发的形式在内部协同集成。它的优点是可以完成端到端的交付而不需要依赖其他团队。团队本身具备进行快速业务创新和探索的能力，也可以与领域子系统协同完成目标。它的缺点是：前后端开发整合需要更多的协作和沟通成本，需要迭代规划。这些开发细节和沟通等待会产生很高的认知负荷，影响整体效率，挑战团队能力。同样，方案B中，赋能团队和可能领域子系统团队缺一不可。这两个团队的存在避免了组织沟通障碍导致的规范、实践、重复造轮子、能力不足等常见问题，尤其促进了跨组织特性团队的低摩擦交付和绩效。但是方案B还有一个问题就是通常端到端交付的节奏比较快，留给后端提前设计的时间不多，所以很容易出现在开始的时候文章（返回原点）：前后端并行开发，集成时，后端API为前端重构设计，耦合度高，前后端比-端人员不能灵活匹配业务的节奏和复杂性，在前端和其他后端，或者后端和其他前端连接调整的情况下，会造成浪费。如何解决这些问题？根据业务变化，动态调整前端和前端工程师的比例。人员协调成本高，团队成员体验差，成长不利。Web开发前后端能力全栈，Story前后端协同，灵活匹配开发任务，提升团队能力，理解端到端业务和落地同时;但同时，也让团队的整体认知负荷偏高。架构越复杂，成本越高，同时也会影响整体的开发效率；还要考虑人才的成长和发展。适当增加全栈的比例，前后端分离，让全栈同学做“自由人”切换前后端开发任务。自由人越多，团队整体的应变能力越强，对自由人的挑战和依赖也越大。在我的采访中，1、2、3已经被很多团队尝试过或者采用过。大多数团队的前后端比例调整在1:2到1:4之间。受访同学都提到了两个决策因素：要尊重当前前后端技术的发展趋势和不同的生态，各有不同的关注点和特点，要努力实现业务目标。那么，有没有其他的解决办法呢？从《高效团队协作模式》一书中，我找到了另一个答案：在考虑这个问题时，出发点仍然是康威定律的指导。我们会发现一个项目的结构不是一成不变的，它会随着业务的变化而变化，在产品的早期、成熟期和规模化阶段，结构都是不同的形式，为什么我们不能使用一个动态的视角来看待设计我们团队的沟通结构呢？答案很明显。于是就有了下面的解决方案：假设业务和技术的复杂性和规模随着时间的推移而增加。Then：在交付初期，业务和技术的复杂度都比较低，需要业务快速上线完成价值转化。前后端更多的是搭建基础页面和模型。同时，团队刚刚组建，需要端到端的理解业务的价值。Web开发的全栈更容易促进团队的形成，规范和实现业务目标。在交付中期，业务开始增长，引入了复杂的业务流程，用户体验需求增加。前后端的技术复杂度也随之而来，比如页面渲染、交互操作、引入微前端、数据一致性、业务可用性等都开始有了更高的要求。同时，代码量达到一定程度，在耦合和内聚方面也有不同程度的质量要求。这个时候开始引进前后端专家，以赋能角色提升的方式与全栈团队协作，解决技术难点，干净的代码治理，赋能规范和相应的前端-端、后端工程实践等，提升整体工程效能。在交付成熟期，随着业务规模的发展，系统架构变得更加复杂，用户数量也随之增加。除了功能特性，在页面加载性能和数据安全方面也会提出新的要求。同时，多端产品服务也会出现，开发者生态的形成也将推动后端形成平台的能力。这些变化将有助于前端和后端团队的逐步分离。此时前后端团队也会适当增加转向架构和特定领域的技术专家，可能会增加特定领域的团队，而大前端的工程师补充开发能力前端+Bff的要求。总结一下，前后端分离本质上是技术分离，而不是人员分离。团队要不要分，取决于你的架构是怎么设计的，也取决于你的商业模式，你服务的产品形态，团队能力，工程实践的成熟度。前后端团队分离的成本非常高，对团队能力的要求也非常高。不适合业务不明确、交付优先级变化频繁、交付速度快、不断创新探索的业务。从个人成长的角度来说，区分前后端并不重要，重要的是自己的发展目标和项目机会是否匹配。团队不应该是我们成长的障碍，而应该是促进我们成长的平台。本文中的讨论不涉及移动应用程序的开发。如果您的架构同时包含Web和Native应用程序和小程序，那么您的团队结构是如何设计的？
