前后端分离的开发模式,这两年确实被炒得如火如荼,导致这个话题也成了面试极其爱问的一个问题,尤其是换工作、跳槽,之前不管你是做后端,还是前端,都可能会涉及。
面试官常问:
其实在回答这个问题时,尤其程序员,一谈到这个问题,上来就一头扎进了某项具体的技术中去了,比如什么:Ajax异步请求、 Vue组件化框架、 RESTFul接口规范、 API接口数据约定、 Mock平台和数据等等。
恕我直言,这估计很难成为面试官内心想要的答案。
因为站在面试官的角度,这个问题大家如果仅仅以某项具体技术、框架来切入,他会觉得你的理解其实很局限。因为很有可能你只知道有前后端分离这个概念,却不知道为什么要做前后端分离这件事情。这尤其对培训班出来的小伙伴,如果只谈到这个深度,就非常危险了。
而且社会上很多公司、团队的一个误区就是:为了做前后端分离而做前后端分离。
以前很长的一段时间里,在一个搞开发的公司里,其实后端工程师是比较有 “门面” 的,往往也是项目和公司的核心团队。这种观念甚至影响了现在很多的应届生求职,都挤破头想去后端开发岗。
那个时候前端开发肯定也是有,但直言不讳,那时候的前端开发人员压根就没什么话语权和公司地位,仅仅是一小撮人散步在团队的小角落,甚至在很多团队里,前端开发都是后端工程师兼任的。
你回想一下,那个年代用的JSP技术不就是这个样子吗?我们就以JSP举例。JSP就是前、后端耦合在一起混着做,套个模板可以把大家弄得死去活来。
这种开发模式在以前那个互联网服务还不是那么繁荣,Web化趋势还不是那么明显的年代,发挥着巨大的作用,大家用得还算开心,毕竟页面不复杂嘛。
但随着社会信息化程度加深,各种各样服务都Web化以后,很多前端展示的东西都变得复杂起来。不信你去数一数淘宝这种网站的页面树,简直太复杂!这时像JSP这种模板技术就没办法高效开发。
究其本质原因,还是因为前端这时候并没有工程化、模块化和可复用化。但那时候的后端不一样,一个Spring这种工程化的开发框架就可以撑起半边天!
所以你想想,这时候开发必然会出现各种不协调、低效率、甚至推诿扯皮的问题。所以从公司项目管理的角度来看,这种开发方式就会非常影响开发效率,所以项目管理者们开始想办法来解决这个问题。
所以你们说应该如何解决上面的问题呢?
解耦呗!
大家有没有发现,在软件领域,任何复杂问题面前,高内聚、低耦合这个法则几乎都能见效!
所以:
说来说去,前后端分离与否,它本身并不是一个技术问题,而是一个项目管理的问题。
自此开始,前端独立出来了,单独行动了。那技术上的问题又怎么解决呢?
自学过前端开发的小伙伴可能会有一种感觉就是:我去,前端这玩意怎么这么琐碎和玄学!知识非常零碎、不易掌握、学了就忘!
很多人学习、甚至工作了都还是东拼西凑、复制粘贴,copy代码段、东拼西凑,靠往上堆积来完成需要的页面和效果。
你会感觉前端这玩意它就是没有Java后端开发这么有逻辑、易管理、可复用!
所以直到像 Vue.js, React.js等这些前端组件化框架的出现,它才从本质上颠覆了前端开发的游戏规则!我们称它前端组件化框架,但我们更愿意叫它前端工程化框架。因为自此开始,大家都遵循一套体系来进行约束性开发,前端开发迈向了工程化、组件化、迭代化之路!
而且前端代码也更好复用了。自从有了 Vue.js等这种组件化框架的出现,别人写的现成按钮、菜单、布局,我们直接拿过来用得不是挺爽嘛!典型的比如像饿了么的 ElementUI,以及蚂蚁金服的 AntDesignUI,这搁以前哪能做到。而且随着 Node的出现,前端开发可以借助 Node来开发各种各样的工具来辅助高效的开发,比如各种包管理器、预编译工具等等,这也是前端开发步入工程化的一个重要的方面
换句话说:到底怎样做才是一个比较优雅的前后端分离呢?
一个正常的软件开发可以简化成四大步:设计、开发、测试、部署,所以真正的前后端分离应该渗透到每个步骤中去。
设计的第一个层面当然是系统设计:后端系统设计较好理解,主要是系统架构、数据库、中间件、缓存等,主要考虑性能、容量、扩展性、维护性;那前端也应如此,假如网站非常复杂,页面极其多,这时前端项目架构也需要做好规划,尽量满足长期演进、可迭代的目标。
设计的第二个层面就是接口设计:前后端系统通过接口进行交互,这时模型( Model)层面的接口约定极其重要,包括:接口请求方式、数据类型、数据格式等。开发前,前后端双方评审到位,都认可之后方可进行下一步开发,否则未来在开发过程中,前、后端开发工程师永远在为了某个破接口扯来扯去!
各自按照事先评审好的接口独立开发,互相无需扯皮。
现如今,前端在诸如 Vue、 React等当下火热的组件化框架的加持下,的确可以独立驱动页面,数据则从事先规划好的 Mock服务器去拿,完全不依赖于后端。
后端则只需要把接口写好,按照先前评审好的约定提供数据。不管后端用Java的 SpringBoot,PHP的 Laravel,亦或是Python的 Django、 Flask,这些都跟前端没关系。而且后端一套接口可以提供给多种类型的前端使用,譬如:Web网页、手机APP、微信小程序等等。
基本上要保证的是,前后端独立可测试。前端主要就是页面、跳转、展示、输入、传参、响应数据的展示等;后端主要则考察数据格式、校验、异常情况、数据一致性甚至一些权限问题。
前后端项目独立部署,这个很关键!在以前的JSP模板时代,前端的html页面、css样式、js效果均由后台来驱动。那个时候所谓的项目部署上线,其实指的也就是后端项目的部署,前端“所谓的”发版本,还是得求着后端来做的。
前后端分离后责任就清晰了,前端项目单独部署。前后端发布上线完全独立,双方可以按照各自的版本规划来发布版本,前端发版本不再受后端约束,后端发版本前端也可以不知道,互相透明了。
还有一个必须提的就是,很多公司里,后端项目都是通过诸如 Jenkins等 CI系统去做持续发布,一键部署,同理前端项目也应该拥有自己的CI系统。
最后一个问题: 前后端分离吹得这么邪乎,它真的就没有缺点吗?
这个问题就要回归文章开始的讨论了,即:为什么会有前后端分离这件事情的出现。
怕就怕很多公司为了前后端分离而做前后端分离。前后端分离需要成本!尤其当你想做一个彻彻底底的前后端分离,不管是人力成本、开发成本、工具成本、还是部署成本,都是不小的。
不顾实际需求,强行前后端分离开发只会带来麻烦,因为只要落地过程中某一步做得不彻底,就会带来很多负担!毕竟并不是所有项目都适合前后端分离!
还是那句话,前后端分离与否,它本身不是一个技术问题,而是一个项目管理的问题!
**本文旨在梳理整个Java后端的学习路线,所用图片/思路来自b站up主codeSheep,羊哥搭建的网站也有详细的学习路线:原文链接