前后端分离已经是老生常谈的话题了，甚至再谈前后端分离显得比较落伍。之所以想谈谈前后端分离，是因为在这种分工模式下实实在在的遇到了一些问题。这篇文章希望对前后端分离做一个简单的梳理。
尽管前后端的分离已经不再新颖，但仍然有很大一部分企业由于历史的原因，采用的是“传统”的Web开发模式，即前端人员根据UI做好HTML页面，再将HTML页面交给后端开发人员打通数据和调试。这是最为“原始”的方式，甚至有可能在如今的大学课堂中仍然是这样的教学方式。我想前端开发人员被“鄙视”也即是这样的开发模式所导致，因为前端几乎不做任何的调试，可能只是调整下页面的一些工作。这样的开发模式也很简单，看起来是对后端开发人员要求更高，也就是要求后端开发人员掌握一定的前端基础。
但随着前端的发展，一些年轻的公司或者年轻的项目也早已对前后端分离进行了实践，前端不再只写HTML页面，后端也不需要掌握前端JavaScript基础。因为在前后端分离的开发模式下，前端和后端被实实在在的所隔离，后端代码中不再将前端代码写到工程中，前端和后端只专注自己的领域，这样的开发模式但也带来了很多的问题。
后端开发人员不再参与到前端的开发，测试变得更加的抽象
以前后端开发人员写完一个功能，只需要启动程序，打开页面就能自测，这是一个很具体的也很容易的一个操作。但是在分离过后，前后端代码隔离独立部署，后端开发人员在开发过程中不能再依靠页面去点击测试，唯一的方式只能加大单元测试力度。尽管每个开发者都知道单元测试的重要性，但我相信这又恰恰大多数开发者都不重视。
文档的重要性变得更加重要
一个人写代码可以不需要文档，因为我知道我要怎么做，我也知道我要怎么变。但一个系统的开发者不再是你一个人，恰好是需要和另外一个人合作的时候，这时候文档就变成了前后端开发者的“契约”。既然是契约，那契约的制定需要变得更加谨慎，一个经常变动的契约会逐渐失去对它的信任。曾经数据的传输与交互是由后端一手制定，并且是“心中有数”，但前后端分离后，前端需要知道后端的数据格式，后端需要知道前端需要什么。这实际上是对后端开发人员提出了更高的要求，一是一份完善且详尽的文档，二是尽可能的考虑周全。
前后端的冲突可能加大
举一个很简单的例子，一个页面往往由多个模块构成，后端开发者返回的数据中只包含了某个数据的主键ID，前端开发者一个页面甚至一个功能需要多次请求才能拿到数据。我相信前端开发者更希望返回的是我需要的所有数据，而后端开发者又想把这个事交给前端去做。
在这里引入一个概念：Bandend for Frontend，BFF，服务于前端的后端。如果前端分离后，前端所做的工作仅仅是数据的一些展示和少量的一些业务逻辑，我认为这个时候数据的整合业务的逻辑应该是交给后端去做，特别是如果是微服务的应用，后端应该是各个微服务的聚合，再将聚合的数据一并交给前端。但仍然有另外一个场景，前端不仅是用某个框架做了数据的展示，还使用了Node做服务端，此时我认为后端就不再去做数据的聚合，甚至可以说直接去掉后端，再换句话说此时Node也就是后端，只是时代变了，前端的开发人员取代了后端开发人员。
