前后端分离意义
一、总结
1、低耦合，提高工作效率，每人明确分工
2、全栈工程师少
3、json：前后端交流通过json
4、前后端工程师不必要分的，必须了解E2E的整个过程
二、前后端分离优点
对于前后端分离的意义我们也可以看做是前端渲染的意义，我主要总结了下面四点：
1.彻底解放前端
前端不再需要向后台提供模板或是后台在前端html中嵌入后台代码，如：
<!--服务器端渲染 -->
<select>
<option value=''>--请选择所属业务--</option>
{% for p in p_list %}
<option value="{{ p }}">{{ p }}</option>
{% endfor %}
</select>
这是前后端耦合的，可读性差。
<!--前端渲染 -->
<template>
<select id="rander">
<option value=''>--请选择所属业务--</option>
<option v-for="list in lists" :value="list" v-text="list"></option>
</select>
</template>
<script>
export default {
data: {
return {
lists: ['选项一', '选项二', '选项三', '选项四']
}
}，
ready: function () {
this.$http({
url: '/demo/',
method: 'POST',
})
.then(function (response) {
this.lists = response.data.lists // 获取服务器端数据并渲染
})
}
}
</script>
上面是前端渲染的一段代码，前端通过AJAX调用后台接口，数据逻辑放在前端，由前端维护。
2.提高工作效率，分工更加明确
前后端分离的工作流程可以使前端只关注前端的事，后台只关心后台的活，两者开发可以同时进行，在后台还没有时间提供接口的时候，前端可以先将数据写死或者调用本地的json文件即可，页面的增加和路由的修改也不必再去麻烦后台，开发更加灵活。
3.局部性能提升
通过前端路由的配置，我们可以实现页面的按需加载，无需一开始加载首页便加载网站的所有的资源，服务器也不再需要解析前端页面，在页面交互及用户体验上有所提升。
4.降低维护成本
通过目前主流的前端MVC框架，我们可以非常快速的定位及发现问题的所在，客户端的问题不再需要后台人员参与及调试，代码重构及可维护性增强。
三、Web 前后端分离的意义大吗？
问题：
前后端分离的意思是，前后端只通过 JSON 来交流，组件化、工程化不需要依赖后端去实现。 可以通过 Angular 或者 FIS-Pure 等，以实现组件化；通过 FIS 之类的工具去做工程化。 有哪些好处或弊端？现在的发展趋势是否往这个方面发展？
解答：
没必要分太细。我们需要 specialist，但是 senior 的人都应该了解整个 E2E (end-to-end) 过程的。
在 Facebook 我们不分前端和后端，只分 product 和 infrastructure。做 product 的通常都是 full stack，不需要对特定的技术非常精通，但要求学习能力和灵活性足够好，不能只做自己 comfort zone 以内的事情，do whatever it takes to get your product shipped。通常聪明的应届生都会先进入 product，因为他们学什么都很快，也不会说浪费了在某个领域的积累。infrastructure 拥有更多各个领域的 specialist，前端只是其中之一。infrastructure 的客户就是 product，要做的事情就是让 product 开发实际产品时觉得爽，就这么简单。
至于真正 senior 的人，必须了解整个 E2E 过程。这有点像那个「在浏览器地址栏按下回车后都发生了什么」的答案，也就是掌握大局同时了解细节。因为具体的问题可疑扔给 junior 的人去解决，所以 senior 的存在价值就是在众多问题当中寻找值得解决的问题。学过计算机体系结构的人都应该知道，性能优化只应该在瓶颈上做，因为做在非瓶颈上就是浪费资源。同理技术或产品的优化都应该是做在瓶颈上的，所以 senior 的人应该熟悉整套系统并且能够有效找到当前的瓶颈。这时候就不存在前端或者后端的概念了，因为 specialist 在特定领域再精通，不了解整个 E2E 的过程就没办法再往上提升。
提到「联调」，我想说我很久没听说过这个词了，因为这个词没有对应的英语版本，美国公司的产品开发过程通常不包括联调。product 要做什么，就自己学习对应的技术，学习公司内部的 infrastructure，然后调用公司内部的 API 就可以了。一个产品的逻辑，要分前端和后端两个团队的人实现，然后还要协调实现的结果，这我只在中国公司见过。当然这不仅仅要求公司 infrastructure 好，还要求有开放的文化。我进 Facebook 之前只写 JS，在 Facebook 要用 PHP 我随便学学就开始写，反正写得不好 code review 时会有人指出。只要保持开放的学习心态，同一个错误不要一犯再犯，别人都乐意帮助你进步。现在我的 PHP/Hack 就仅仅是够用的程度，但这不妨碍我工作。我的工作当然要用到别人的 infrastructure，偶尔用起来有点小不爽，我就会想要改动一下。管它是 Python、Java 还是 C++，反正我不爽就必须亲自研究源代码弄懂了自己该。原本的作者不一定有时间处理我的小需求，我就按照我的理解去改，改好提交 code review，别人都会帮忙看然后提点建议。
所谓联调，无非就是有些事情你自己做不了非要以来于别人帮你做，然后别人就会成为阻塞你的环节。（通常都是前端依赖后端，很少有说后端因为前端没完成就必须停下来等的。）这种做不了就停下来等的态度是不对的，不能说那是别人的问题就等别人解决。总之阻塞了产品发布的问题就是你的问题，无论需要你学习什么新技术，无论需要你编写和调试什么不熟悉的代码，do whatever it takes，just get the product launched。
那个木工和电工的比喻大致也是对的。在中国公司，这就是木工和电工的分离。在美国公司，有一帮人使用 3D 打印机、激光切割机、数控机床，外加 Arduino 或 Raspberry Pi，迅速把新一代电子产品的原型做出来；还有另外一帮人研究新一代的 3D 打印机，考虑如何让上述 maker 更快地把头脑中的产品原型变为现实。在中国公司，木工和电工整天吵架，木工说电工不把线路板面积确定下来他就没办法做木盒子，电工说他在电动机大小不确定的情况下线路板没办法定稿。