麦都-平台开发组

关于前后分离,我想说说

写作时间:2018-08-29

前方预警:这不是一篇纯技术文章。


先说说我经历的前端开发模式吧。

  刚接触前端那时候,招聘网站都是“美工”,当时进的公司是小作坊,一个人包揽整站,设计、html、css、jquery,然后套用开源的CMS系统做数据渲染。这个阶段,一个jquery库就能做到老板拍手点赞。

  随着前端社区的崛起,开始有了专属称谓“前端开发”。那时我喜欢折腾些样式和交互,慢慢开始重心转移到了“前端”。随着jquery的使用,开始关注还有个玩意儿叫ajax,于是毅然的辞职,找了一份“前端”的工作。

  随着业务的复杂度,前端代码和文件也越来越多,开始关注前端性能,当时还用一个小本本写下业界军规“雅虎十四条”。当你意识到这个问题的时候,前端社区也出现了相应的工具。蛋疼的是,都是些手动在线压缩,来来回回复制粘贴的操作,就这样极差的工作效率,当时还觉得很神奇,时常跟同事分享发现的新工具。手动雪碧图(css sprites),手动合并压缩文件等“手动模式”的开发方式,玩得乐此不疲。

  随着不同终端的兴起,业务越来越复杂,对开发人员的要求也越来越高,为了提升开发效率,开始走出了前后分离的第一步,ajax + js模板引擎。感觉前端开发一下子高大上起来,前端社区出现一些不曾见识过的概念,什么运行环境,什么构建工具,什么包管理器,觉得自己做了一个假前端。慢慢发现只使用jQuery已经无法满足业务需求了,开始接触各类框架,才明白库和框架不是一回事。

  前端MVC、MVVM框架的涌现,让前端开发的效率提高不少,web开发已经成为一个很复杂的工程性问题。组件化,就是后端玩的那一套思想,前端搬过来实现自己的生态系统。现在的技术发展变化之快已经到你无法预知未来了,前端社区的蓬勃,我还有很多的领域需要去熟悉和学习,以后会发展成什么,我们都不知道。


再说说我对前后分离的理解。 

  现在公司的部门就一两个前端,而且一个人负责几个项目,之前的项目大多是前后端强耦合,因而前端没有什么代码组织结构可言,前端只负责切好页面扔给后端,项目也是以后端代码结构为标准。虽然有前端分离意识,但不知道如何去实践。我最开始有个误区,使用Angular/React/Vue之类的框架,前端实现业务逻辑就可以了,然而这只能叫前后端分工。

  前后分离是架构上的事情,而不是职位和工种的分离,第一次做肯定很痛苦。分离是架构的选择,决定你如何管理、分配与协调现有的资源,如果个人能力强,你可以做全栈,但全栈也是建立在架构之上的。当然分离后你是做SPA还是其他模式的应用,那完全是你的自由,但也不是说前后分离目前都很成熟,去构建一个分离体系是会有挫折有代价的,但你不去做就不可能成熟,代价也不是不可以有,关键是看长远的利益。

  这涉及到前后端分离的利弊问题,前端或者后端开发人员也许认为后台套模板的开发模式完全没有问题,前后分离是瞎折腾,之前不分离的项目做起来很顺利,分离后反而给自己带来了额外的工作量和学习成本,我只能说,这就取决于开发人员的技术能力和见识了。

  当然,我不是鼓吹所有项目都前后分离,一个产品的轨迹是需要产品研发团队自己把控的。前端有个普遍的特点,你让他写个页面信手拈来,但是你让他负责一个完整的业务就抓瞎了。为什么?因为他们涉足太浅,HTTP协议?不懂!Ajax?见过没用过!jQuery请求API?没用过!Promise?不懂!模块化?听说过!探索前后分离并不是像很多旁观者说的“为了分离而分离”,反而是“为了更好的理解web开发而分离”。对应web开发,该懂的都应该懂,否则你就是坐在同事身边那个只会“追求像素级还原”的页面仔。

  探索和实践前后分离还有一个重要的好处,能够让你的前端开发团队摸索和整理出一套自己的开发体系,即便是不分离的架构,让后端的资源用在更重要的底层服务或业务逻辑去,把那些页面UI交互,和数据层有着小小关联的业务交给前端独立去完成。

  但是分了就表示架构合理吗?肯定不是。要想分离好,前端开发要了解后端架构,后端开发要虚心学习JS。前后端只通过JSON来交流,组件化、工程化不需要依赖后端去实现,需要搜索引擎带流量的项目,必须做服务端渲染。

  前端可以把我们擅长的事情做得更好,而不需要后端小哥哥们操心,我们可以省去很多后端数据渲染的工作,让他们专心写好自己的代码,我们的分离是为了更好的专项精通、协作和管理。在学习和工作尚有余力的时候勇于探索吧,本事学到手才是最重要的,坚信:你是一个工程师,不是一个页面仔!