前后端分离的一些质疑
发布在大搜车前端团队专栏2015年8月7日view:13073YiksiAssow前端开发
在文章任何区域双击击即可给文章添加【评注】!浮到评注点上可以查看详情。

前端工程师想做前后端分离不是空穴来潮.没分离前的流程是,前端管视觉交互,然后把页面给后端,(偏前的)后端去拿数据套页面,两个工作环节.这样的流程,自然有些问题.

以我们公司为例,后端工程师是要对我们写的页面进行修改的.经过一轮修改后,标签不闭合是经常出的问题,一个页面,这种情况有可能反复出现,这就让人很恼火.不过负责任的后端也会反思,而且现在的工具,对闭合的检查都已经很不错,新开发一个页面,其实这种流程可以接受.

但是除了开发,还要维护.后端是jsp,那么不可避免的,出现问题,前端要去修改jsp.jsp这种落后的技术,当然不想去学,所以都是看着其他地方的代码,猜测jsp的语法,然后应付了事.修改的时候,不一定只是样式和文案的修改,有时要涉及到数据,这时候就免不了要前前后后来上几个回合,自己交流成本啥的都上去了.

另外,为了看修改后的样子,我们前端工程师是要启动java环境的.虽然我有些java基础,但是生态环境这块,不经常玩,是玩不转的.经常性的启动不起来,天不怕地不怕,就怕后端让更新.一更新,之前的环境就有可能因为缺少java包而报错,一个上午就在不断的mave clean,install,之前这是常态.现在情况有所好转,但是该个样式,启动那么大的一个java工程,实在不爽.隔三差五的,还提交一些java代码,总感觉哪里不对.

所以,最基础的想法: 维护的时候,前端能不去关心后端的环境吗.于是,后端服务化,我只要调用接口就行.这样前端开发环境分离出来,后端用什么东西,改什么东西,都和我无关.想着想着,就觉得体系一下就清楚了,世界很美好.

但是毕竟是个工程化的问题,工程中,很多情况并不是那么单纯.要对现在的开发结构做很大的调整,我们内部对这事争议很大.正好这次D2上,有些嘉宾分享了相关的工程经验,但是听完后,我依然有很多质疑.

1 人员的质和量


(-_-!好吧,我拿着底层程序员工资,考虑着部门leader,甚至技术总监的事)

目前看,前端还是挺缺的,前端中,有能力再去写nodejs的,就更少了.而后端中,会写增删改查,套套页面的人,相对要多不少.

现在分享前后端分离经验的公司,是什么量级的公司,大家也都能看到.而且,我个人对他们的结论还是保持警惕的.因为方案他们做的,检测他们做的,报告他们写的,好不好他们说的,这让我想起了之前参与过的一些科研项目…(省略10000字吐槽…)

D2上,花瓣网的嘉宾说,他们有24个前端工程师,想做一些前后端分离的事,但是估计前端的工作量应付不过来.那么问题来了…请自己衡量吧,反正我听了后,是有点害怕了.

2 职责明确


这一点应该是前后端分离最看重的结果了.但是,有些情况下,反而不明确了.比如

现在有个页面,出现了问题,产品过来找前端,那么有些经验的前端,可以在不启动任何开发环境,短时间内,就能看出,这个问题是样式,交互问题还是数据问题.
如果是数据问题,那么按照传统分工,我马上就能对产品说,这是后端出的问题,你去找他(内心银荡一笑).

前后端分离后,因为数据的显示逻辑,是前端工程师在做.问题稍微复杂一点,就需要启动开发环境调试,然后花费很长时间确定,这到底是谁负责的问题.

从开发新功能的角度,前后端分离是职责明确了,对于维护的时候,修bug的时候,就不一定了.

3 改变的前端的一些特质


前端相对于后端,基本不需要对业务有什么了解,对一家公司的耦合度是很小的,换一家公司,不需要对这家公司的业务多做了解,上来就能做事.价值上来讲,就比后端要差很多.

之前是前端管视觉交互,然后把页面给后端,(偏前的)后端去拿数据套页面,两个工作环节.现在是前端把第二个环节也做了.公司的一些后端就认为,根本不是前后’’分离,就是一些公司前端工程师能力达到,劳动力也比较丰富,把之前一些不属于自己的活,抢过来做了(我表示他们说的有一些道理,不好反驳).

那么现在,你的工作量提高,你需要了解的技术知识多了很多,当然这对于有追求的前端工程师, 都不是事.但是,也必须对公司的业务要有比较深的了解,就我个人来说,是不想主动去学习这部分知识的.

比如,有个订单业务,有4种订单状态,每种状态下,根据条件的不同,又要隐藏一定的东西.那么传统上,我把四种    状态按着设计稿全切完,ok了,订单的流程,逻辑,我完全不关心.

前后端分离后,就必须要对这个流程非常清楚,每种大状态下的小情况也要清楚.你必须学一些很boring的东西. 不过当你对公司的业务越来越了解,并且没有你的代码,公司的业务就跑不通,那么你在公司的地位和价值就上去了.有得有失.如果能带来待遇上得显著提高,也不错,但愿情况是这样.

4 开发依赖


接口规定好了,前端是不依赖后端的,自己伪造一份不是啥难事.但是后端套页面,必须依赖前端的工作.串行的模式,影响效率.

但是前端做了2份活后,本质上还是串行的..

5 性能


体系上加一层,一般是为了更加清晰的结构,减少耦合度,但是性能可能会有损失.

听大牛的分享,说前后端分离,(一般)加nodejs一层后,性能提升,我是没法理解.后来知道,后端服务化后,nodejs把一些以前套页面拿数据的过程,从串行变成了并行,所以性能提升

后端服务化后,为啥java套页面不能并行化.这是站不住脚的.只能是以前的后端,该做的优化没做.当然很多时候,一点性能损失远没有结构清晰,维护方便重要.


总结

写了5点.

第四点,第五点只是觉得嘉宾的一些结论,有值得商榷的地方.

第三点看实际情况下个人的权衡.

第二点,挺让人难受的,有些理想化的东西,可能站不住脚了.不知道有没有啥方法解决或规避掉.

第一点可能是现在最致命的因素.所以让我们再纠结一段时间吧.

评论
发表评论
4年前

@Storm 从修改来说,后端开一个共享或者ssh,你直接改的是他机器上的文件,不需要你自己本地配置环境 你们公司是这样玩的,后端随便允许前端在他的电脑上改代码??有没有其他更好的方式

4年前
赞了此文章!
5年前

其实还是人多了.不干点活,怎么算KPI呢? 从修改来说,后端开一个共享或者ssh,你直接改的是他机器上的文件,不需要你自己本地配置环境,还说JSP这么落后的技术..都不知道根据什么猜想出来的.. 另外,不懂数据和业务逻辑的前端,都是页面仔.别指望公司会对这类人有什么倚重

5年前

如果是用jsp写的话,前后端分离很难,因为jsp需要容器,不太好做mock服务。 神猪碰到的问题我们之前几乎碰到都是一模一样的问题。 现在前后端分离做的也还好,因为我们把jsp换成了freemaker,而通过自己开发的grunt插件,可以将mock数据的json文件与freemarker的模板进行渲染,生成html文件,再配合node.js开发的ajax mock server,基本在开发阶段,可以与服务器端并行,并且不用服务器端同事套页面了。 但这其中的坑还是有的,比如,数据接口的定义,前端自己定义了自己需要的接口,但服务器端根据数据库或一些业务的需要,定义的模型与前端完全不一致也是有可能多,有时候碍于工期,服务器端同事可能不会去为前端再去映射出一套接口,于是前端就需要修改使用了接口数据的地方,同时还要修改mock数据,有时候也挺麻烦的。。 前后端分离还得慢慢摸索啊。。

5年前

500人的公司也只有十几个前端,分离不了,还是老老实实的传统流程中。

5年前

@飞天小黑神猪 node纯转发,本质上是把以前的后端模板比如freemarker,改成node平台流行的模板比如ejs,其实没多大意义

5年前

谢谢神猪分享

5年前

@小鱼儿-lovefishs 支付宝那个,我仔细想下,已经不是单纯的前后分离了,基本是用node web 把以前很多java web的事给做了.其实这需要用node 做纯转发就好,这个才是最基本的前后分离,这样的hold住的难度就还好了.不过后端同学的阻力,还是很大.

5年前

总结的挺好的,这个分享我也去听了,虽然没有什么实质性的收获,但是开拓了视野。前端是一个变化很快的行业(个人认为),从无到有也是在迅速的演化完善中。分离这样的路我想应该是必然要走的,只是就好比,10多个人的公司就不要去考虑1000个人的公司的事情,作为自己研究是好的,如果真要套在工作项目里去,还是需要观望一段时间的(起码我感觉现在还没有什么实质性的开源的东西可供参考),同时自身的技能也要hold住才行。

5年前

@前端乱炖 回复一楼,不是为了技术而技术,技术是体现在解决当前的问题之上,再能服务于未来的。

5年前

第一点是最至关重要的没错,但思路就是人员质量本身就参差不齐,还混杂在一起时工作效率就更低了,更应该逐步地把两端分离开来,这样两边都只需要关心接口而非各种细节,效率才有可能提升,才有可能解放人力不足的问题

5年前

@飞天小黑神猪 我拿着白菜钱就先不操白粉的心了,前后端分离到底怎么做,我暂且持观望态度,看看大厂们的践行成果再说(等支付宝分场的视频出来了,我去瞅瞅)。

5年前

@Saviio 感觉有点被支付宝的解决方案左右了.node纯做转发就好了,java可以和之前基本一样,就是jsp不用套了,仅此而已.node也不用管安全啥的,这样的方案,对小公司还是有可行性的,感觉也成熟可靠很多.

5年前

@飞天小黑神猪 最后就回到hax老师很早以前问过的一个问题,「前端们拍着胸脯问问自己计算机素养到底如何了」,因为这些问题的难度都不是以前切切图啊或者写写轮播可以比拟的了,而是深入到协议栈上和整个web体系内部进行开发和应用了。

5年前

@Saviio 顺着你的看法,这样就是让后端一个个的都要成架构师,前端要深入了解web开发的各个方面..理想挺好,但是人力上,支撑不起大规模流行.

5年前

@Saviio 你比我思考的深入多了,比如安全性的东西,我就没考虑到…基本上,总归按捺不住一颗躁动的心,想去试试,但是觉得问题实在比较多

5年前

@前端乱炖 我的态度也是可以先试试,不然已有的问题永远不能解决..只是,没试之前就能想到一些问题,是不是要在考虑周全一些.另外,有没有其他的一些方案.

决定做了,就要认真做,做之前要想好

5年前

这次D2听了好多前端工程化和前后端分离的课题,但支付宝的那次分会场没去听,粗略的谈谈浅见吧。

实际,现在在普遍推广的前后的分离的其中一个主旨就是把前端在整个开发流程中位置后置,完全由前端去处理客户端request->生产信息->客户端response的这个过程,而后端则专注去处理和生产数据。但具体实现起来则有一个前提,就是已有的FE的能力能否cover住,比如路由,比如部分攻击防御(不仅仅是XSS和CSRF了),更具体的话则是HTTP协议相关内容,Socket相关应用,etc。

当然,这样来做,好处是有的,一是FE的价值得到了提升,二就是FE真正能决定究竟以什么样方式把信息来提供给用户,比如CORS的配置,比如websocket的花样运用。坏处就是,由于FE的来源混杂,五花八门,以大部分FE的知识结构来看,能拥有这方面素养的人还是少数。

至于你说的性能,我是这么理解的。

数据的并行化实际上取决于后端在服务端渲染这层采用什么样的编程模型,假设一样是开线程从各个模块拿数据,页面耗时也就等于Max(taskQueue.map( (q) => q.cost) ),那所谓的性能提升也就无从谈起了。但引入node.js的原因也同样来源于此,只不过通过libuv的抽象,自动将获取各个模块的数据步骤转换成并行,不需要后端人为的开线程提供优化。而后端的优化也就更进一步的后置到了DB->Server这层io上了。

5年前

有些东西,大家都说不清楚,有利有弊,这时候,尝试一下也是好的,大动干戈程序员应该感到兴奋,而不是畏惧

5年前

那天,跟开发之间吵了两个小时,最后口山舌燥,但是吵得多了,我反而越发鉴定自己的想法。做改革,产生新问题是正常的,最重要的是你大方向对不对,抱的目的对不对,是不是解决了现存的一些问题。【不为技术而技术】以前我在阿里反对前后端分离,因为大家纯粹为了KPI去推一些无意义的事情,但是现在抱着解决问题的态度而去,通过不同的方式去尝试新的东西,如果被证明是无意义的,那当然需要淘汰。

PUBLISHED IN
大搜车前端团队专栏

大搜车(souche.com)前端团队的一些研究和总结性文章。欢迎订阅。

我的收藏