现在大部分前端新人只写「前后端分离的代码」，所以很难理解前后端分离的边界在哪里。
其实判定很简单：如果前端和后端只通过简单的 API 文档就能进行数据交流，就说明他们的逻辑是分离的。我们可以称之为「前后端代码分离」。
如果除了 API 文档之外还需要各种其他的数据交流方式，比如后端把数据藏在一个 div 的属性里，那么就不是前后端分离的（因为这根本就不算是一个 API，只能算是一种「私下约定」，但是在实际工程中，总是会保留一两个这样的约定）。
这看起来是一句废话，但是很早之前的 Web 开发确实没有这个意识。导致页面代码杂乱，PHP 中有 JS，JSP 中有 JS，ASP 中有 JS，JS 中有 HTML，HTML 中有 CSS，HTML 中还有 JS，JS 中还有 CSS，CSS 中还有 JS（比如 IE 这个死浏览器）。
代码一点也不「分离」。这种代码结构根本就没有 API 的概念，只有数据在各处流窜，极难维护。为了鄙视这种代码，才有了前后端分离运动。
但是要注意：前后端分离不代表前后端代码是两个人写的，如果代码是两个人写的，那么就是前后端「分家」。如果代码是一个人写的，这个人也不叫做「全栈开发者」，应该叫做 「Web 开发者」，流行的叫法叫做「大前端」。
前后端人员「分家」必然导致前后端代码「分离」。前后端分离的初衷是用「单一职责」原则把代码质量提上去，很难想象为什么之前的开发者连这么基本的原则都不知道吧，其实是因为以前没有 AJAX 这项技术，而且前端代码太少了，不值得花时间分离。后来突然 Web 大爆发，JS 代码和 CSS 代码从几百行跃升到几千行甚至几万行，不分一下就说不过去了。
前后端分离的一个不好的后果是让前后端人员分家（矫枉过正）。分家的问题我已经吐槽好几年了，不过之所以大公司喜欢让前后端人员分家，也是有一些客观原因的（康威定理）。（其实我很想说前后端分家就是错的，但是好像大家不喜欢听，那我就中庸一下吧）为了防止有人扩大概念，我举一个明确的例子。
某大型 Web 应用，后端服务全部都是 Java 提供的 service（如数据服务）（并不是 HTTP service），业务部门的开发者需要使用 groovy 调用 Java 服务使用 groovy 响应前端的 AJAX 和 HTML 请求使用 JavaScript 做前端界面这三件事都是一个开发者完成的，这就是一个 Web 开发者要做的事情。
他不需要自己去写 SQL 语句，也不需要自己去连接 Redis。上面的 groovy 可以换成任何你喜欢的语言，比如 Python、Ruby 或者 JS，都一样。这个时候如果你要问前后端分离在哪里，其实没有什么意义。因为既然前后端都是同一个人，其实不写文档也没事（当然还是写文档更好），如果你一定要他写文档，也是很简单事情，因为代码都是他写的嘛。而且他自己在前端调用 HTTP 服务的时候用的就是 AJAX + JSON 的方式，这很分离。
这么做的最大好处就是节省人力和减少沟通时的信息损失。另一个好处就是让你多学一门语言（我知道有些人认为多学一门语言是坏处），还有一个好处就是没有什么蛋疼的「前后端联调」了。
总之：前后端代码分离是百分百正确，而且是现在的主流，但是要不要分家（分成两个团队，一个前端，一个后端）则是值得商榷的。因为每次前后端撕逼和联调都是效率的瓶颈请区别对待前后端代码「分离」，和前后端人员「分家」。
如果你司已经把前后端「分家」了，那么基本上前后端代码也是「分离」的。但是如果你司没有让前后端「分家」，那么前后端代码可能是「分离」的，也可能是「不分离」的，如何判定前文已经说了。前后端分家的对立面并不是全栈，而是 Web 开发。未来的趋势是大前端，也就是我上面说到的 groovy 的例子。
閱讀更多 前端小學生 的文章
