作者|端庄无论你设计什么样的系统架构，最终获胜的还是你组织内部的通信结构。这个观点在组织中被反复证明，但也不断被忽视。前后端分离的优缺点近年来，随着微服务架构风格的引入，前后端生态的快速发展，以及多端产品的出现，前端-端后端分离已经成为业界通行做法，也是大规模的企业级分布式架构。的默认选择。前后端分离也给软件技术人员的职业发展和协作方式带来了新的变化。分别涌现出前端工程师、后端工程师、前端开发团队、后端开发团队。前后端分离，让前端专注于信息架构，处理与用户体验相关的问题；而后端侧重于构建业务能力、数据处理、持久化等，向前端提供API接口（API即产品），供前端消费。前端工程师不需要关注后端的具体实现和技术框架，后端工程师也不需要关注前端的具体实现和技术框架。这带来了以下好处：前后端用户体验和业务逻辑解耦。不同端和不同用户体验的变化不再影响后端API接口。后端API侧重于表达业务能力，可以同时服务于多个产品，无需改动。后端无需考虑业务逻辑或能力升级对前端的影响，只要接口不变即可。响应变得更快。对于前端，尤其是多端服务出现后，前后端代码分离和打包部署技术分离，可以更快的响应不同的用户体验需求，无需等待后端-结尾。前端和后端工程师以能力为主，可以专注于各自领域的技术学习，专注于提升自己的专项技能和经验。前后端团队边界清晰，减少认知负担，单点开发效率高。只需要关注本端的开发任务和技术。分离的好处逐渐体现出来，尤其是在一些大型的互联网项目中。但是，也有很多交付团队是前后端分离的。出现以下问题：团队开发业务的规模和复杂度随着项目的推进而变化，导致前后端团队比例失衡。后端团队联调，或反之，后端团队等前端情况，开发进度不顺利，沟通协作成本高。这种临时性的任务变更，无论是增减人员的动态调整，成本高，体验差。业务发展节奏快，留给后台预先设计API的时间不够。前端团队只能靠自己的猜测和共识进行开发。联调时，双方分别进行变更，返工率高，沟通协作成本高。API的设计也受到前端消费者和开发节奏的影响，是面向前端用户体验设计的。同一组件的多个模块之间有许多不同的方法。所以，前后端团队不分开是行不通的。当然，前后端人员不分的协作模式，可以灵活匹配开发任务，提升全栈能力，团队也可以了解端到端的业务；但同时也使得团队整体的认知负荷偏高，架构越复杂，成本越高，也会影响整体的开发效率。那么到底要不要区分呢？什么在影响我们的架构？组织的通信结构决定了软件架构。康威定律：设计系统的组织是受约束的，而那些设计往往是组织内部通信结构的副本。会不会，其实答案很简单，就像文章开头提到的，无论架构如何设计，无论我们作为技术从业者为更好的架构和技术付出了多少次努力，我们仍然会看到“为什么我们不能得到我们想要的吗？”最重要的设计，为什么明明是结构却不同。”因为，在这场交锋中，组织的沟通结构最终必胜。确实如此。从上述的恶趣味和这些“前后端分离团队”的代码也可以看出：/stock-schema/customer-detail/stocks/createAndNext/stocks/query-list?稍后再写页面
