链接：https://www.zhihu.com/question/28207685/answer/39893889
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
意义很大，但是你的问题本身认识有偏差。
对于前后端分离，认识上有个误区，那就是很多人自称：我们老早就分离了，全AJAX，使用Angular或者什么什么就可以了。
这个说法是不合适的，打个比方，别人问的是“如何解决家禽把蛋生在水草边的问题？”，但实际上人家养的是鸭子，答题的却是养鸡的，所以回答“不让去水边就行了”，这显然不在点子上。
这两年业界说的前后端分离，是限于偏展示类的系统（用A代替），而不是应用、管控类Web项目（用B代替），在B类项目里，前后端是天然分离的，对此，除了少部分后端开发人员，基本所有人的认识都是一致的。上一段中这样回答的人一般都是只做B类项目，在B类项目里，前后端分离是共识，不需要讨论。
那么，剩下的问题就是讨论A类项目的前后端分离了。这个问题的核心在什么地方呢，在于模板的与数据结合的位置，以及，模板的控制权在谁手里。经过这两年的讨论，基本上我们可以达成的共识就是：模板应当由前端人员去控制，主要原因有两方面：
- 性能优化（尤其是外部资源的管理与发布，请求合并等等）
- 协作的顺畅性（已形成模板的界面片段的返工等问题）
那么，模板到底应该在什么地方跟数据结合？
这个问题就比较折腾了，有部分人尝试像B类项目那样，使用js模板，然后在浏览器端执行，这是存在一些问题的，比如说seo不友好，首屏性能不够，尤其对于首页DOM量很大的电商类网站，差距很明显。
所以我们还是得把主要的模板放在服务端来执行。在这个过程中，阿里作了一些尝试，那就是引入Node层，在这一层把模板与数据进行合成，然后浏览器拿到的就是生成好的HTML了，但也不是所有HTML都是这么生成好的，还是会有一些内容等到了浏览器之后，再用js去加载和生成。nainaitea.com
所以这一定会是一个混合方案，同一个系统中存在两种模板，一种在服务端执行，一种在浏览器中执行，互为补充。
至于说这个方案中，是否中间层一定要是node，我觉得无所谓，只要是能正常做web项目的东西都可以，这个还是要看所在企业的技术积累方向，当然node做这块是有一些优势的，比如对前端人员的语言友好性，前后端模板的通用性等等，但这些都是细节，重点还是整体方案和流程。
这时候回头看你问题中的这句：
> 前后端分离的意思是，前后端只通过 JSON 来交流，组件化、工程化不需要依赖后端去实现。
我相信你这里对前后端的限定是以浏览器为准的，但事实上，A类项目中，前后端的分界一定要延伸到服务器端的模板层，也就是在这一层里，把各种来源的数据整合到模板中，这个数据未必是JSON格式的，会存在有JSON，XML，特定的二进制等等。
组件化这个话题就更复杂了，在刚才组织形式中，很难说出究竟什么才是组件。是某个商品的模板吗？是数据吗？是数据和模板的结合体吗？没法回答。在此，我说一句自己的看法：像电商这种项目的前端部分，基本不存在组件的概念，甚至不存在组件化的价值，因为这里面可复用的东西太少了，也不易提取，大多数东西都是不带逻辑的界面模板。
最近因为ReactJS的流行，带来了一个Isomorphic的概念，这是一种很有意义的探索，但是否能解决这类问题，尚不得而知，根据我的理解，它对B类项目是较好的补充方案，但对A类项目暂时还缺乏可用性，因为A类项目中，运行期的DOM变更并不多，多是整片的改变，用这个方案去解决的话，有些牛刀杀鸡的感觉。
关于B类项目的组件化，我之前那个没写完的系列是关于它的，但经过最近一年多的思考，我又觉得需要再重新写一篇东西了。感谢你的问题提醒了我，这就写。
谢邀。
首先，我给
的答案点了赞，因为本司（百姓网）也采用Cat讲的Product/Infrastructure的分法，尽管我们还有许多不完善之处。但是大家也许知道我非常推崇前后端分离。看上去似乎有点矛盾。
一句话解释：我推崇前后端分离是在于技术架构上，而不是组织/流程、职位/工种的分离。
我认为最有效率的方式始终是——让每个人发挥他（她）自己最大的潜能。所有组织/流程、职位/工种的限定，是为了更好的协作，而不应该限制人能力的发挥。
如果人的能力强，当然可以full stack。且小团队肯定效率更高。反过来，跨部门联调这种事情，必定非常低效，且多后患，应极力避免。
可是full stack工程师至少目前是可遇不可求，大多数情况还是像
讲的直接从应届毕业生培养。但每个团队最初的核心成员不可能是应届毕业生，你至少需要有几个资深工程师作为种子full stack工程师。facebook或许可以招到许多能力超强的人才，但大多数公司招不到，即使是BAT。市场上有工作经验的技术人才往往只是熟悉某个特定领域，因为他过去积攒经验值的地方本来就是这样分工，从而限制了他成为full stack的可能——这是又一个鸡生蛋蛋生鸡的案例。
因此，即使我们采用了小团队协作的方式，团队内部也难以做到都是full stack，还是有前后端分工。只是这种分工不是基于职位，而是基于能力现状。
另一个情况是，即使一个工程师在facebook的团队里可以full stack，但换个团队很可能就不行。
提到了两个前提：infrastructure 好，开放的文化。两者缺一不可。小公司常缺前者，大公司常缺后者。本司后者很好，前者还不够完善但仍算OK。但是我们仍面临困难，这就是我要补充的第三个前提：合理的人员配比——这点容易理解，你可以不熟前（后）端，但是至少团队里有人是较为成熟的前（后）端，否则连能review你代码的人都找不到，成长就更无从谈起。我司最近就面临这样的情况，业务线发展太快导致新开项目的团队配不齐人。在这样的情况下，不得已就得放低要求，采取前后端分离的工作方式——是的，前后端分离的方式对人的要求是更低的。还有一个问题是
提到的：“对于个人职业规划来说，横向发展的风险往往大于纵深发展”。我个人并不完全认同这点，且我看到至少在前端领域许多由于分工过细导致技能发展受限的悲剧。但是，如果缺乏纵深发展的可能，确实也会是个严重问题。我认为必须给予工程师遵循自己兴趣和能力决定自己发展路径的自由和支持。技术架构若能很好的分层——比如良好的前后端分离，将有助于工程师进行纵深发展。而这反过来也可以促进横向发展，因为工程师可以更自由的在多个层面上转换。
以上就是我的想法——Web前后端分离和full stack不是互相矛盾的。相反Web前后端分离的技术架构能更好的帮助我们走向product/infrastructure的组织架构，并且能让工程师更自由的发展。
没必要分太细。我们需要 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 更快地把头脑中的产品原型变为现实。在中国公司，木工和电工整天吵架，木工说电工不把线路板面积确定下来他就没办法做木盒子，电工说他在电动机大小不确定的情况下线路板没办法定稿。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
