怎样看待前后端分离开发

前后端分离的起因

在软件领域里任何复杂的问题面前，高内聚低耦合这种原则几乎都能见效，所以前后端的事情分开来做我要把前端开发的责任从后端开发工程师身上拿掉，要给前端开发工程师一个单独的岗位和责任领域。要给前端正名，不能让人们总是使用野生的开发模式不能一天到晚去copy html代码段、js代码段、css样式，人肉去试错、去调试等等，前端也需要工程化、项目化的思维来做，所以这才是前后端分离开发模式最开始的来源。所以那个时候这个思想的来源不关vue、react等这种框架的事，他们只是后来的一个具体的实现方式而已，所以从本质上看，前后端分离本身并不是一个技术问题，而是一个工程化考量和项目管理的问题，自此前端开始独立出来了。

传统的开发模式：

前后端分离开发模式：

那技术上的问题又怎么去解决呢？

前端不能像以前那样猥琐发育了，从这个地方开始，我们才开始讨论具体的技术，所以vue.js、react.js等这些前端框架的出现，他们从本质上颠覆了前端开发的游戏规则。
我们叫它：前端开发组件化框架
但我们更愿意叫它：前端开发工程化框架
因为自此开始，大家都遵循一套体系来进行约束性的开发，前端开发也越来越工程化、组件化，越来越有章可循，而且前端代码也更好复用了，而且随着node的出现前端开发也可以借助node来开发各种各样的工具，进行辅助开发，比如各种各样的包管理器、各种各样的预编译工具等等，这也是前端开发迈入工程化、迭代化、可复用化的一个很重要的方面。

前后端分离到底要如何实施呢？

一个正常的软件开发简化来讲应该有四大步设计、开发、测试、部署，所以真正的前后端分离应该渗透到以上的每一个步骤中去，这才能算的上真正的前后盾分离。

• 首先第一个阶段设计阶段：设计的第一个层面当然是系统设计，后端系统设计比较好理解包括：后端架构、系统架构设计、数据库、中间件、缓存等架构的设计，主要是考虑性能容量扩展性可维护性这些，
  那前端也应该如此，假如你的网站页面极其多、非常复杂这时候前端项目架构也得做好充分的规划和准备，一定要满足一个长期可演进可迭代的目标，当然设计的第二个层面就是所谓的接口设计，前后端分离之后，前后端系统通过接口进行交互，这个时候模型（model）层面的借口约定极其重要
  包括：接口的请求方式、数据类型、数据的格式等等，这些东西一定要评审到位，不然在未来的开发写代码过程中，会发现前后端开发工程师永远在为了某个破接口扯来扯去

• 第二个阶段开发阶段：前后端各自按照事先预定的接口独立去开发，不需要扯皮，一旦前后端开发人员为了某个接口的事情出现扯皮，这个开发称不上严格独立的前后端开发 ，因为总有一方要被迫去改东西，去妥协，其实这样还是有耦合，前端现在在诸如vue、react等这些当下非常火热的组件化框架的帮助下，确实可以去独立的去驱动页面，独立的开发，数据也可以从先规划好的mock服务器去拿，数据全是模拟出来的，完全不需要依赖于实时的后端接口，而后端也只需要把你的接口写好、提供好，按照之前评审好的接口约定来提供数据就可以了，而且前后端分离之后，后端一套接口可以提供给很多类型的前端使用，比如web网页、手机qpp、微信小程序、h5页面等等。

• 第三个阶段测试阶段：基本上是要保证的是前后端独立可测试，前端主要就是页面、跳转、展示、输入、传参、相应数据的展示等等这些测试，而后端主要保证数据接口的提供、数据格式、校验、异常情况、数据的一致性问题、权限问题。

• 最后一个阶段也是特别重要的一个阶段：部署上线阶段，前后端分离之后，前后段项目可独立部署，前后端分离之后，前端的所有事情都可以全部自己单独去做，前端项目也可以去单独独立的部署，而且前后端发布上线可以完全独立，双方可以按照各自的版本规划来发版本，前端发版本不受后端约束，后端发版本前端也可以完全不知道。后端项目可以通过Jenkins系统去做这种持续发布、一键部署，同理，前端项目也应该有自己的CI系统、也可以去持续发布、一件部署。

前后端分离的必要性

前后端分离确实是很适合复杂的项目，但是前后端分离是需要成本的，尤其是想做一个彻彻底底的前后端分离，不管是人力成本、开发成本、工具成本、部署成本都是不小的，有些小团队或小项目如果不顾自己的实际需求，强行前后端分离式开发，只会给自己找麻烦，因为只要前后端分离某一点做的不彻底，就会带来非常多的负担，而不是便利性了，所以说并不是所有项目都适合前后端分离的，要看性价比，所以前后端分离本身不是一个技术性问题，而是一个工程考量的问题