Web前后端分离
前后端开发模式已经成为一种“政治正确”了。当然，这种模式的确是分工明确、开发高效的。同时，与前后端分离开发模式相对应的，实际是FULL STACK——全栈开发模式，这种神人一般是可遇不可求，采取前后端分离的开发模式本质上是为了降低人员与技术要求水准，以保证业务的开发与推进。
但是，前后端分离的开发模式并不是银弹，特别是在较小规模下的微服务开发模式中，采取基于流程和工种的前后端分离开发模式未必是好的选择。
微服务背景下的前后端分离
首先，我们必须要说明的是，微服务并没有要求一定要以前后端分离的模式运作，这只是一种选择。
一般而言，使用前后端分离模式开发主要有以下两个原因：
- 移动互联网时代，底层业务逻辑可能是一套，但前端可能存在桌面端、移动端、App端等不同的呈现渠道，这时就需要实现横向的分层；
- 中台概念的盛行，也为业务横向分层提供了条件；
从以上两点可以得知，如果只是做传统的Web单体系统，典型的BS应用，那么前后单分离就不是必选的，反而针对不同后端业务划分的微服务，前端应当拆分为不同的微服务，不应当融合为一体。
这里，举一个笔者的例子：
笔者所在的开发项目中，使用了微服务以及前后端分离的开发模式。
后端根据不同的业务侧需求，被划分了不同的微服务，彼此之间干扰较小。而前端则并没有做划分，被完整的包成了一个微服务，每次升级也是全量功能打包升级。
这就造成不同后端微服务会给多个前端开发人员提需求，前端开发完合入了主干分支，但此时不同微服务后端上线不可能同步！每次前端发版上线总是要与每一个后端微服务对齐功能上线情况，确保后端代码已上线到生产，否则就会出现前后端不一致而生产接口报错。
同时，如果某一个微服务后端接口有问题，由于前端是单体微服务，从而只能全量回滚，但这又会造成其他后端微服务对应的前端需求无法满足。
总之，混乱不堪，根本不满足微服务的拆分原则。
其次，对于小规模的开发团队而言，盲目执行前后端分离的开发模式，很容易因为某一个前端人员的离职而造成整个项目的停摆，后端干等。
同时，当执行前后端分离的模式后，又会出现这样的问题：究竟谁应该为某一个业务功能负责？
如果没有前后端分离，功能从设计、后端开发到前端实现都是一个开发人员去实现的，自然是这一个人来负责。
但是当采取前后端分离模式后，事情就变得复杂：后端人员只负责提供API，而前端人员需要提供实际的功能页面以及业务逻辑对应的接口组装执行。
这种造成这样的问题：
- 实际上，前端的开发人员对整个业务逻辑、数据处理机制并不熟悉，ta只能按照相应的逻辑将API接口组装起来。简单来说，只要能保证点击一个按钮能将数据查出来，点击另一个按钮能将数据存进去，前端的工作就已经完成了。但是，业务逻辑到底有没有实现、功能是不是完备，前端既不关心、也无从验证。
- 按道理来说，这样的逻辑与功能的验证应该由后端人员来完成。但是从笔者的实际体验来说，后端开发人员基本不会特别的到前端页面中来实施业务流维度的完整黑盒测试，只会去做简单的接口数据准确性与可用性验证，更不用说目前所提倡的“开发者自测试”，甚至连专业的测试人员也被砍掉了。而落实到开发者自测，后端人员也至多会写一些简单的UT、APITest，满足接口测试的覆盖率即可，并不会对完整的业务流程去做详细的测试。
因此，这样的现象就造成一个特性维度的功能上线，反而没有一个人会为其功能的可用性与具体质量负责。很多问题只有在现网用户实际使用时才会暴露出来，不仅影响服务交付质量，而且会造成大量的返工和变更。
这里的负责，并不是出了问题以后谁背锅，而是说没有人会实际关注这个问题。因为不管是对于前端而言还是后端而言，都会认为自己已经完成的需求的达成和功能的完整交付，但更高一层维度的业务功能，恐怕只有SL或PM来关注了（笑
当然，如果在开发前架构师和产品经理能够对需求做详尽的分析、对API做具体的设计，后端开发人员能对API做充分的UT与APITest，上述业务功能的质量是能够保证的。
不过就笔者观察而言，由于连轴转式的特性交付、赶鸭子上架的功能开发，上述要求想要满足，基本不现实。
简单思考
最后，笔者并不是否定前后端分离的开发模式。这样的开发模式确实效率很高，而且对开发人员的要求也会降低。
但是，对于像传统B/S应用的Web开发，在项目规模较小的情况下，推行前后端分离的模式也需要仔细探讨。
同时，对于我们开发者自身而言，除了在对自身垂直领域的技术深耕之外，适当的了解横向领域的相关知识也是很有帮助且必要的。
