前后端技术分离为什么能提高整体效率和产品质量？

非诚勿扰孟非

前后端技术分离为什么能提高效率？
一些外站的文章都在说分离的本质是就是「工作有了分工」，然后用了一大堆「莫名其秒的专业名词」去解释「作者自己怕是都想明白的事情」。

原文地址：https://www.zhihu.com/question/64017039

继续前进

私以为主要是为了降低工作人员技术门槛，其次是减少各向工作人员撕逼，再次是服务器能少干点儿页面合成的活儿，降低一点儿负荷来省钱，最后才是利用ajax等方式合成页面减少页面跳转提升了用户体验。
总而言之，其实还是省钱。
真要说开发个东西靠一个人包圆，用不用彻底分离可能更多看个人喜好，分离了反倒要写更多代码，要做接口，要写渲染，甚至要做SEO，就工作总量而言是更大的，除非就要追求单页应用的酷炫效果，又或者做成大一统容易思维跟不上趟，不分离当然更轻松。
但是，要找个既精通前端设计又熟悉后端逻辑，能用模板语言把两者糅合在一起，还都精致可靠问题少的人不那么好找，于是乎工资开得高还不容易招；反过来，找个专精前端的再找个专精后端开发的就容易许多，工资也能开低点儿，人多一点也能一定程度加快开发。
可是这样两个（或者更多）人协作就免不了撕逼，如果页面是直接在服务端合成的，有些东西服务端可以算，页面上也可以算，两方谁都不想多事，出了问题也免不了相互推卸责任。前后端分离了就能事先写个文档来约定接口设计测试，文档和测试就成了分工和责任划分的基准，谁的锅一目了然，撕逼范围撑死卡在文档理解差异上，更方便管理，人力成本和管理成本都顾及到了。
至于附加效果，前后端不分离的话页面在服务器上合成；分离了则在客户端（浏览器）上合成，前者占自己的计算资源，后者占用户的计算资源。这年头大家都在坑用户的计算资源，各家的电脑性能不差那么点，就连手机性能也能扛得住，经得起坑。你不分离，同样的访问量下，你的服务器成本就比别人的高。分离了更便宜。
最后的用户体验问题，其实通常来说普通用户反倒不那么在乎一两次页面跳转（甚至分辨不太出来是不是页面跳转），再说项目大了就算前后分离也是很难撸成单页应用，意义并不是特别大。

卡卡

架构上有一种叫Monolithic Architecture，不解耦，不分模块，不分离（至少是不刻意追求），代表性的例子是Emacs。
Emacs的开发效率，高不高？只要你能驾驭（Elisp）是很高的，很多时候程序可以一气呵成，问题是学习曲线高。
Emacs的质量如何？见仁见智。总体来说会Lisp这种偏门语言而且还能用好的，也差不到哪里去，不是说Lisp语言优异，而是能选择Lisp来写东西的，应该是发烧友级的码农，这种码农本身水平不赖，能驾驭根本，架构就是个皮相。
至少Emacs Core的质量是相当高的，不少代码行云流水。
现在来回答问题，分离的根本原因还是因为人本身对复杂度掌控的能力限制，一个中等规模的web项目（多语言，多抽象层次），要让团队每个人都通前后台都不是容易的事，其实很多时候根本是不现实的，东一个patch西一个patch可能还行，商业开发讲究成本受益，快速开发最后还不就是个成本受益问题，所以要让一般的码农写出还行的应用，而不是找精英的码农作出只能他们自己驾驭的东西。这是分离分层这种方法论出现的内在原因，这和大应用部署不能单服务器而要集群是类似道理：好伸缩。
效率和质量也许受一点方法论影响，但本质上，效率和质量取决于“人”的水平，“人”不行，分离是错的，分层是错的，方法论成教条，你可以要求团队每天早上standup，每几个礼拜retrospective，正儿八经SCRUM，隔三差五架构会，MicroService，但核心环节如数据设计者却没人做得精当，方法再好也无济于事，重要的事做不好，方法代替不了人做好重要的事，只是一种辅助。错误是“人”犯下的，问题是“人”制造的，真正的效率和质量，来自于“人”本身。

队长是我

前后端分离可以提高质量好理解，因为特定工程师在前端或者后端可以做精做深，但要说前后端分离提高整体效率，这个还真不一定。
当组织和产品变大之后，整个系统不可能由一个人或者一个小团队来开发维护，毕竟一个人一个小团队的能力有限，从方便管理的角度，要分开成多个团队，这是水到渠成的事，但随之而来的就是各个团队之间的交流沟通成本。
如果各团队之间的沟通成本很大，那效率肯定上不去。
我在微软Exchange的时候，深刻体会到这一点，前后端分离，要开发一个日程表上的功能，前端团队在北京，后端团队在西雅图，设计团队又在西雅图另一个楼，开个跨洋会要早起或者晚归，一次讨论没结果又要下一次。为了开发一个功能，前端有前端的想法，后端说后端有后端的局限，设计团队脑子里又总能蹦出一些奇怪想法......这是非常考验项目管理能力的，要是项目经理不强，最后不要说效率不高，最后做出来的东西也是四不像。
所以说，前后端分离未必提高效率。
任何时候，能够让一个end-to-end的控制一个功能的实现，是最高效的做法，但是又回到老问题，一个团队的能力有限。
怎么办呢？把工程师团队分为两种，一种负责开发平台和框架，另一种负责开发应用功能，这样，平台和框架团队可以把各应用通用问题解决，然后应用团队只需要少数人就可以和搭积木一样快速开发应用。
这是比“前后端分离”更先进的管理方法。
了解更多软件管理方法请关注
@程墨Morgan

大力水手

It depends。看团队规模，看项目复杂度，看复杂度集中在哪边。
如果是1-3人团队，项目复杂度不高搭积木，积木已经写好有所积累，那么前后端融合开发效率最高，竖切。
团队再大，积木层分离框架层分离，业务层依然竖切，前后端融合；
再大，继续专业分工横切加业务竖切，根据实际情况排列组合。
大到一定程度，不光前后端分离了，每个层都分离了。业务层依然多个人，按模块竖切。
软工实践只有更适合团队，没有绝对优势。不分情况的前后端分离，就是懒加踢皮球。
大到一定程度，踢皮球是注定出现的。
举个简单例子。
页面A需求两组不太相关又有点相关的数据（a,b，定语是说，从代码结构角度，放在一个接口和两个接口是都可行的，是模糊的，不存在语意上的明显优劣），数据a在另一个页面B也提供了单独接口获取，但如果拿 a 数据在页面 A 需要进行重新组织。
这样，接口定义可以有两个方式：

• 接口 I 提供a 数据，接口 II 提供 b 数据，前端发起两个请求，并对 a 做额外整理后使用；
  
• 接口 I 提供整理后的a,和b 数据，前端直接获取后可以直接影射到界面逻辑。
  

两种方式，前后端分离团队一定扯皮，都想对方做复杂的，自己简单化。就算嘴上不吵，心理也都有数的。一般是后端定接口，后端但凡老油条一点，一定把皮球踢给前端。前端但凡老油条一点，一定会去吵。
要么，根本是  俩 团队，而不是一个团队的两个组，那么也简单。吵不到一起去，我给啥你吃啥。
要么，团队之间关系很好，大家乐意为了共同目标考虑最佳实现（开发周期，各自进度，处理难度）。
要么，不分层，竖切，同上。
要么，引入接口编写人，独立于前后端团队的系统工程师，他写接口文档，前后端都照着做，我说是啥就是啥。

以上场景，我不信前后端分离团队没遇见过。

清风寡欲

何老师您这创业都事必躬亲到这个程度了么-_-？
前后端分离你也管？
Ok，不从技术的角度来解释，我们来谈一下管理和开发流程。
说两个关于效率的事实：
一、一般说来，除去非常复杂的纯技术项目，大部分项目，开发人员会把大量时间“浪费”在沟通上——比如前端要和产品沟通，和 UED 沟通，和后端沟通。
二、多人项目一定会涉及“协作”问题，具体到开发领域，最频繁的协作就是联调和发布。这两件事最讨厌的地方在于开发者之间的依赖——本来我可以回家的，但是为了陪你联调，我要加班；本来我可以按时发布，但是由于你 delay 了，于是我也 delay 了。
那么刨除产品和 UED，一个 web 开发团队最理想的状态是什么呢？是 0 沟通、0 依赖，我开发自己的模块不需要跑到任何人的工位上去了解任何事情，我发布我的模块不需要任何人帮我做任何操作。
当然这是不现实的，但是至少是把现场沟通和现场依赖降到最低，是正确的提效路线。
前后端分离，就是把前后端作为分界线，从以上两点作为切入点，提高效率的手段。前后端分离并不是把后端模板改成前端 js 代码，就分离了，前后端分离是个贯穿开发全流程的概念。
首先是开发分离，前后端使用分离的 codebase，前端按照后端 api 文档撰写或者生成 mock 数据，在开发过程中不依赖任何后端服务配合，后端同样按照 api 文档撰写或生成 api 调试工具，开发过程中不依赖任何前端页面配合（这一点被很多前端架构师所忽略，但是后端写的爽也是很重要的）。
第二是发布分离，前后端各自发布自己的版本，发布过程中不需要对方在场。出现了问题各自回退，对对方也没有任何牵连。
第三是测试分离，由于后端只输出 api 接口，于是可以很方便的进行自动化测试，可以提早暴露问题，并且测试成本很低。而前端由于不依赖后端数据，于是可以随时输入任何数据，产生可预测的效果，这对测试也是很有利的。
其他的好处还有很多，比如前端开发过程中我可以将我的本地页面连接到任何我想连接的服务器，比如任何后端的开发机。再比如前后端分离模式下同一套后端服务可以很好的支持多端、多版本客户端，等等。
总的来说，前后端分离想要达到的效果就是前端和后端不需要说太多话，不需要坐在一起，不需要陪对方加班。一切协作尽量基于文档和工具进行，实现真正的“异步协作”。
反过来说，如果引入了前后端分离后，没有达到这样的效果，或者效果不明显，说明方案没设计好，或者没执行好，总之就是没打中痛点，还有提高的空间。