别再吹前后端分离了

1,336 阅读5分钟

前后端分离,被网上抄的如火如荼。但真的有网上吹的那么神吗?还是为了追新而追新,为了分离而分离?事实上,我开发过的项目并没有感觉到给我带来了多少便利。总之,前后端分离,人不分离。分离后前端对之前的要求更高了,只会前端三剑客是远远不够的。这就有了学习成本,还得处理耦合,跨域什么的,所以让我感觉到并不是那么便利。

一提到前后端分离,脱口而出的就是一些技术,比如spring,vue,react,node,有了它们我们才可以去进行前后端分离。但是仔细想想,是技术导致分离吗,还是需要分离才有了技术。显然它并不是一个先鸡后蛋的哲学问题

万恶之源jsp

遥想当年,我们小团队主要是后端为主,作为项目组的攻坚核心力量,也在干着前端的活。当时也有专门的前端,但不多,也叫“切图仔”,主要帮助后端搜集一些模板和处理一些图片资源。当时前端要求不高,web化趋势也不明显,jsp就好似其汽车中五菱宏光,发挥着不可估量的作用。后端也被奉为一个有技术含量的岗位。但从2020年初开始,甲方逐渐变态,需要前端展示的东西也复杂起来,jsp弊端也逐渐放大,模板套模板,东拼西凑,没有规范,导致开发人员经常扯皮。从项目管理的角度看,这种开发模式非常影响项目开发效率,怎么办?那就解耦。“高内聚,低耦合”果然是永远滴神。所以前端越来越被重视,市场缺口也越来越大。前端的责任逐渐从后端人员身上拿掉,逐渐形成了一个单独的岗位及责任领域,前端也开始逐渐像后端一样开始工程化,模块化、项目化。

大人时代变了

我认为的分离应该是互不影响的,耦合极少的(只需要沟通好接口规范就可以)。站在本身做后端的角度,我用Java也好,PHP也罢,不用管我怎么实现的,最终给前端的只是一串协商好的接口数据,也可以给多个类型前端去用,比如web,手机网页,小程序等等。一次开发,处处使用。站在前端的角度来看,我需要的数据完全可以去从mock服务器去拿,不能傻呵呵的等你后端给我数据。不存在谁等谁的问题,拒绝扯皮,以缩短开发周期。

优雅的分离

如今的前后端都已经成熟,都可以单独的进行工程化开发。前后端分离绝不是仅仅项目单独开发,而是灌输于整个项目周期。

一个通常的项目开发通常有四个阶段,其实在《软件工程》不止四步,但就不空谈兵书了,不能深受八股毒害。只说关键部分。分别是设计、开发、测试、部署。

设计阶段:设计包括系统设计(架构设计)和接口设计。包括不限于数据库、中间件、缓存、尤其要考虑性能、容量、可维护性这些东西,前后端都一样。而其中的接口设计就显得十分重要,它是联系前后端的关键部分,包括不限于请求方式,数据类型,数据格式。一个好的接口设计可以很好的避免前后端人员的撕b。

开发阶段:各自开发,互不影响,尽量减少耦合。就如前面说的后端一次开发,到处使用,前端不用看后端眼色,自己模拟数据进行独立开发。

测试阶段:前端本身作为一套完整的系统,自身可以进行页面的跳转,输入,展示,响应等测试。后端除了进行数据接口测试,还有权限、异常、一致性等问题的一些测试。

部署阶段:独立可部署。我直接部署都是前端用webpack打包好,放后端项目的static目录下,还得重写路径,解决跨域,总觉得哪里怪怪的,这分离了个寂寞,后来才学会分别部署。前端使用nginx就可以单独部署,顺便解决了跨域问题。后端的话用tomcat。Jenkins持续发布。

到底该不该做

说了一大堆,做还是不做。前后端分离终究还是一个工程化考量项目管理的问题。而不是单纯的技术问题。需要考虑成本、人力、开发,工具,部署等等方面。处理不善只会带来麻烦,而不是便利。

说人话,前后端分离肯定需要扩招人手,成本能接受吗?能接受多少?分离不彻底带来的风险能承受吗?彻不彻底与招到的人有关,与带头的项目经理有关。出现问题就会延期,多出的成本问题都是损失。

但前后端分离带来的好处还是很多的

1、站在企业的角度。开发一套,到处使用,初期费钱,后期赚钱

2、站在开发的角度。前端解放出来,开发更加灵活,可以开发更为复杂的业务,例如一些页面交互效果,数据处理。后端终于可以甩开膀子干三高了(高性能、高可用、高并发)。一句话:提高开发效率

3、站在用户的角度。用户体验提升,tomcat终于不用加载静态资源了,减少负载压力。前端按路由配置可以按需加载。交互体验必定提升。客户满意的嗷嗷叫

4、站在维护的角度。更好维护了,不容易甩锅的现象。分工明确,出现问题可以快速定位。兼容性问题,跳转问题找前端,数据出错,校验问题找后端

所以可以粗略认为:大项目分,小项目不分。