18

如题,我是公司新成立部门UEC的小前端,公司以前开发是用python的django开发的,项目经理习惯了前端只是写模板,后端拿来套的形式。不过去年年末,我的boss(uec的总监)向上级提议开始前后端分离的形式,于是招了很多个前端,准备把公司的产品一一做分离。

项目经理却觉得不靠谱,就各种问我这么保证这个安全,那个安全。。。。(最主要的是。。接口吧),由于我是小菜。。。对前后端分离也是一知半解,只知道前端通过接口调后端数据就行了。。。于是我就说数据接口的安全,前端是保证不了的,接口的安全需要后端来保证(不知道说得对不对,但是前端的确没法保证这个的安全啊。。。),当时可能回答的比较急。。项目经理就火了。。就说“你们这是瞎搞,我不管,我们这边已经做得很好了,问题都在你们那边,你们UEC部门存在的意义就有问题”,看他这样,我也就不敢反驳什么了,当时产品还给我解了围(他原来也是搞技术的),跟项目经理说:“接口安全的确是后端的活,我以前做过的.........”【此处省略】。

自此以后,项目经理就各种看我不顺眼,本来该后端处理的数据,直接让他的人粗枝大叶的甩给我让我在前端处理【上千条数据。。就在前端 搜索。。排序 不知算不算多】。然后怪我做的慢,要是前后端不分离项目早做完了,我那个委屈啊?,本来这个项目我来的时候就延期了,当时这个项目还没有后端,我提前把前端部分做完了,等着他们调后端过来,就等了半个月(期间 我去了别的项目 帮别的前端),后端来了,数据调好了,产品在年前那一周又改需求。。。设计不得不赶紧设计,我不得不等设计完继续改页面,增加功能,所以年前没做完,到了年后这周五才做完。。。。,这怪我吗??? 怎么延期的锅就这么甩给我了??

前后端分离了,后端只管数据的事了,只管M层了,所以后端做得快了,VC层前端来做,反倒是他觉得他的后端做得很快了,我们前端拖了项目的后腿。。。 我咋办。。。。我都觉得哔了狗了。。。 已经向我的boss反应了情况(boss是前后端分离的推动者,但是他是设计出身?可能在技术面前话语权 没那么重),心里面还是觉得有点瘆得慌,我在试用期啊。。真怕被刷了。。,我该怎么做,好迷茫。。

2017-02-12 提问
23 个回答
38

已采纳

我比较赞同 @娃娃脾气 的观点。不过这里我不说怎么做人,我准备从技术和管理的角度来说说

首先,我对我带过的所有人都说过一句话:永远不要相信前端。不是说不要相信前端工程师,而是说不要相信前端提交的数据,换句话说,安全性肯定是后端的事情

前后分离是必然趋势,考虑一个问题,你愿意后端渲染页面还是前端渲染页面?假设后端渲染页面平均需要 0.1 秒,前端渲染平均需要 2 秒,20 倍的差距。但是假如有 100 个用户,后端需要花 10 秒来处理,如果阻塞的话,平均个用户要等 5 秒;而前端渲染,每个用户只需要等 2 秒。所以从性能上来说,我个人是比较推荐将页面处理过程前移的。目前各种静态化趋势也在证明这一点。

其次,从设计的角度来说,前后分离可以实现呈现和数据(逻辑)的解耦,这也是一种 SOA 的思想。后端可以专注于处理逻辑和数据,把呈现的事情完全交给前端处理。前后端只需要约定好数据接口(通常是一定格式的 JSON 或 XML),剩下的事情就是各干个的,互不影响;不仅前后端的开发轻松,测试也轻松,测前端可以做桩,测后端可以直接验证数据;如果客户对界面不满意,后端可以去休假,前端照新设计把样式表一换就能解决;如果是对用户体验不满意,前端脚本要做的事情就多一点……不过大部分都有框架实现。换句话说,前后分离大大减轻了后端的工作量,但前端工程师一定要顶得起

接下来就是分工的事情。任何事情,只要是多人(或一人多角色也是同样)合作,就肯定存在分工的问题。分工,说白了就是职责,责任分不清楚,扯皮是迟早的事情。前后分离,从哪里分,分到啥程度,这些都需要预先做好约定,把责任划分清楚。就拿数据来说,几千条数据是应该前端处理的还是应该后端处理的?就按一条数据 1K 来算,几千条也不过就几 M,其实前端处理后端处理都可以。后端处理肯定快得多,而且有缓存优势,并不会造成多大的阻塞,而前端处理除了加载数据慢一点,内存消耗大一点,也不是多大的问题(没人会把几千条数据同时渲染出来吧),那这个就要靠约定了,而约定也不是随便约的,要架构师说话,要不然架构师拿来干啥。架构师认为这地方,前端处理用户体验不好,分给后端处理,前端传参,后端把数据过滤后给出来,那就后端处理;架构师认为这地方前端处理无压力,后端是瓶颈,那就前端处理……分清楚了,自然不会扯皮

如果前端压力过大,后端轻松得不行,那就是项目经理要负责的事情了,这很明显是人力资源安排不合理。就按前后各占 50% 工作量来说,1 个前端对 3 个后端(举例)就是很不合适的安排。而且前后分离之后,很明显后期前端工作量会比后端大得多,所以在不同的项目时期,人力资源如何安排,这是项目经理要干的事情。项目经理要做的事情就是协调好资源,控制好风险,把握好进度,再尽可能的少花钱——我一向不太赞成技术人员做项目经理,做技术和做项目管理思维方式都不一样。

总的来说呢,前后分离不是罪,架构师、项目经理、项目组各成员各司其职,尽量以契约的精神来办事,事情就好办得多。如果你现在认为跟项目经理沟通不下去,找你的上司去沟通,还是沟通不下去,再找更上一级的上司……如果怎么都沟通这不下去,那就没有合作的可能,留着也难受,还不如换个地方发展(如果你只是考虑生存,那就忍吧)。

1
回复 娃娃脾气

项目本身是一个动态的过程,不同的时间会有不同的界限,所以项目经理难当呢

边城 · 2017年02月12日

3

“责任分不清楚,扯皮是迟早的事情”, 这个责任界限会根据项目进度、公司人员技术等级变迁、新需求的出现而变得不再恰当,所以“界限”必须是可变的。那么“界限”怎么定?

娃娃脾气 · 2017年02月12日

展开评论
15

想了很久,还是不知道怎么回答,就说说我的几个想法吧。

  1. 跟着骂一顿项目经理,接口安全问题都拎不清。

  2. 你自己不会推卸责任,本来又不是你推动的,你去和反对者硬肛什么,有人逼逼让他去找项目推动者去啊。项目推动者要求技术协助时你再上啊。干嘛要自己先出头。

  3. 本想说你们不行,太乱,太喧嚣,没法沉下心做技术。。但是转念一想,技术、方案之类的结果,也是要靠博弈,才能有结果的啊。否则就是独裁体系了。

我比较推荐观点2,你得学会推卸不属于自己的责任。

7

首先说一下,你的这个case我现实中遇到过。
你的PM明显是挑软柿子捏啊。。。他技术问题为啥问你这个试用期的新人而不问你们UED team的老大? 项目逾期了来challenge你这个小前端,让你有背锅的负罪感,这是一种十分拙劣的管理手段。
我来分析一下:
PM可能对这种前后端分离方式存在抵触或者因为缺乏这方面的经验对项目存在的Risk产生恐惧,自己由搞不定上面的领导或者其它老员工不买账,一般就会找具体做事的软柿子来捏,先埋下伏笔(质问你不了解的技术性问题,让你懵逼),使你在项目逾期需要加班的情况下处于一种弱势心态,从而任他摆布,或者替人背锅。这种风格的PM我在上家公司碰到过的,我的处理方式是硬肛!当然我处的位置和你不同,我是Role是前端leader,公司的老员工老油条,不会卖这种傻逼帐的,所以一来二往,知道我是个狠角色就不会再来找我麻烦,但是时不时还会去骚扰我的小弟们(捏软柿子)所以我后来直接跑去上上级领导那里challenge他,例数一些此人罪状,不久就他就被fire掉了。不过你作为一个新人我建议你打打太极拳,阳奉阴违一下,把皮球踢给前端leader,作为你的老大会站出来为整个UI team据理力争的。

3

最近的一个cms系统也是前后端分离架构,项目到现在基本稳定,作为这套前端代码的架构者兼主程,还算欣慰。

但是这个过程中后端有几个同事真是太low,死活都不愿意改变一点,期间各种不配合,人家就喜欢jsp模式,下绊脚石、故意拖延,该做的都做了,甚至他们文档也要我们写……几乎所有的数据验证、完整性检查全部交给前端完成,后端收到什么人家就存什么,管什么数据正确与否,甚至在数据库里存时间,人家都用的string类型,也是醉醉的。前后端分离后,前端的代码比后端多出很多,还被领导各种嫌弃前端工作量少,做的慢,其他看热闹的同事也经常放话“前端这么简单随便几下就搞出来”,在这做的心力憔悴没有意思,现在诚心在看好点的机会,有意者请联系:

6年前端经验,
react系,
QQ:"295567363".split("").reverse().join("")
mail:"moc.361@neajeel".split("").reverse().join("")

3

很久以前听到一句话,深以为然:

能够通过硬件解决的,就不要交给软件来做;能够在系统层解决的,就不要抛到应用层;能够在应用层解决的,就不要抛给前端。

2

哈哈,这种问题,不要怂,这样处理~

他提出问题,你反问他,直到让他能说出让你信服的理由为止,他说不出来就会不坑声了,变被动为主动,哈哈~

举个栗子:

  • 他:前后端不安全

  • 你:你为什么认为前后端分离不安全?

  • 他:这个那个不安全..

  • 你:前后端不分离就安全了吗?

  • 他:...

  • 你:...

哈哈~

补充:管它前后端分离不分离,前端都是永远不可信的;分离只是为了解耦;

2

不自信啊。
需要一个前后都通的leader。
这么说吧,去学后端,前后端分离是代码分离,并没有让程序员分离。不会前端的后段不是好web程序员,反过来也如此。前后端分离是大趋势,也能解决很多痛点,但是也是对应着相应的场景和需求。问一下,不分离能死不?若不能死,还活的不错,不分离行不行?有一些又老又旧屎一样的代码,依然对付着跑,也不碍事,不碰行不行?如果贵司业务复杂到不分离就痛苦得不要不要的,应该没这么大阻碍。
再强调,前后端分离不是让程序员分离,更不是分离成两个部门

1

个人比较赞同 @娃娃脾气 的观点。
首先,有些问题跟你关系不是很大不冲上去了无可厚非,但是如果你冲上去的但是顶不住, 那就是对自己认识不清楚。
其次,我觉得领导的问题很大,领导不是头脑发热做决定的人,领导是一个团队的核心。
最后,还是缺一个重量级的能扯的起皮的前端。

1

兄弟,学会把问题抛给别人,不要把自己搞的那么累,不要有那么多情绪,你是去敲代码的不是去打架的,不爽的时候就去阳台吹吹风,反正前端能干,那就慢慢干,事情这么多,我总得要时间吧?做一个佛性程序员,试着以柔克刚,笑里藏刀,佛祖心中留。阿门

0

服务端为服务端,前端/客户端为前端,这个千万别搞混了。

数据最基本的筛选处理当然是服务端做得,不然服务端有何用?

并且提一下,你们的项目经理要么是个弱鸡要么是专门找你麻烦的

0

干的不爽就赶紧走,别要浪费生命了。。。

另外,我能说我们组leader同时负责h5和api吗 ?

0

看了很多同学的分析主要都是讲前后端分离的,我就从另一个面小小分析下

引用作者原话: boss是前后端分离的推动者,但是他是设计出身?可能在技术面前话语权 没那么重

如果boss在技术面前没话语权hold不住自己的领域,在与其他部门谈判的时候,保护不小自己的小弟,无法为自己的部门争取应得的权利,那么boss应该深思一下了

另外对于楼主,我的建议是,你的工作是前端,但是你首先是一个程序员,技术的深度和广度都值得你去追寻.可以利用业余时间学习一些你们的后端语言,相信如果你虚心向后端同学请教并讨好下他们,他们会不吝赐教的.

通过对后端的学习,你会站在一个更高的视角上看待和解决问题,相信到时候你会对前后端分离有自己的理解

最后,是非多的公司,勾心斗角的公司少待.我们程序猿已经够累了,别浪费时间在这种揣摩他人意图,避免得罪人的公司

0

前后端分离肯定是未来,但是前后端所需要处理的问题非常多,最好是有个全栈工程师,而且要资深,并且懂移动端,现在跨平台应用这么多,后端分离是肯定的,我们公司就是用的前后端分离,前端和后端基本没有沟通,除了我定制接口的时候和大家开个会,定制一下文档,然后各自开发各自的,前端直接模拟数据,效率非常高,而且方案清晰。 就算是为了seo也会用nodejs来重建项目,和后端没有关系

至于安全问题,我从来就是说不要相信前端发来的数据,所有的后端都要做数据验证,前端就是裸奔,没有安全所言

0

这个是web开发的趋势啊
后台用任何编程语言实现restful api ,供前端javascript (或javascript框架 调用),改写DOM。

0

我觉得你们项目经理出发点没多大错,如果他是以整个项目的高度来看问题的话,而且搞技术的都有点儿这个...但是后来怼你太过分了。
你自己也说了对前后端分离一知半解,所以如果你想尝试需要团队支持,至少有个扛把子去推动,另外别把自己局限在前端这个范围了。

这几年前端非常火,火到很多人转了前端(我就是其中之一),以我自己的经验,前后端分离没有想象中那么美好,得挑合适的项目,有时候特别坑爹,前端会很累。而且现在前后端分离的概念比较模糊,如果不懂后端,绝逼是个大坑。
甚至我有一种感觉,从我进入行业开始一直就在说解耦,事实上web开发本来就是一体的,很容易进入为了解耦而解耦的误区,现在有一些方案的趋势又走向了反方向,三十年河东三十年河西。所以有时候看到一些特别老的技术方案,有种旧瓶装新酒的感觉。

如果你真是个小前端,这个事你就别主动推了,真想要尝试前后端分离,等待机会换个项目,或者换个公司。

0

先说安全问题: 安全问题与前后端分离无关。
无论有没有分离,最终界面和接口都是要暴露给浏览器的。
接口有安全问题,一定是后端的锅。
页面有xss问题,专业前端一定比专业后端更靠谱。
所以前后分离在安全上,一定是有提升的。

然后说怎么分离:
一个不变的原则,前端只处理界面与交互,以及只和界面和交互相关的数据。其它如用户数据,业务逻辑全由后端处理。

0

我之前就觉得我们前端用play,代码一团糟,然后就力推前后端分离,REST接口+纯前端进行改造,基本框架写好了,但是前端觉得写js太累,不久就离职了。。。前后端分离对前端要求还是挺高的,但是好的web程序员应该前后都懂

0

是个不错的话题,适合在知乎上唠嗑!

首先在确保自己业务代码没问题以及弄清楚什么是前后端分离,然后就是自信点讲道理,我假设你们团队最终的目的还是想要解决问题。

责任不分,职责不明,界限不清,是你们问题的症结所在

你们可能没你们想象中那么清楚

为什么要前后端分离?
什么是前后端分离?
怎么实现前后端分离?
“我”需要做什么?

我在前公司尝试前后端分离拓荒,也遇到过类似的窘迫,当时是做的一个SPA应用,我前端仅处理视图渲染和视图逻辑,虽然我一再强调我只负责 UI Layer,业务处理和数据处理应该是后端负责,但是每每遇到各种数据错误,接口异常(当时负责接口同事是,一个新人妹子,临时招的),PM:“那谁谁你写得页面有问题/bug,你快看看”,这是我那段时间听到最多的话,没办法只有每次强调一次,view 层没有问题,明显是接口数据有问题,然后帮后端后看看接口 ,找到接口问题 && 修复,即便如此一旦项目出现任何异常,我们 PM 都无脑丢锅给我前端...后面项目越滚越大接口问题越来越多,最后我同公司当时大后端(相当于技术总监)连续改了两个通宵后端接口,基本上重写了PHP妹子当时已完成的所有接口,而我也只是由于 pm 和技术总监觉得是我前端出问题了,陪着我们大后端加了两个通宵班,没几天,PHP 妹子被技术总监辞退了。
后来回过头想想,因为当时的团队开发方式比较原始,没有接触过前后端分离,连前后端分工都算不上,所谓的 PM和技术总监都没能弄清楚什么是前后端分离,责任不分,职责不明,界限不清,也是当时我所在团队遇到的问题。

模式没有好坏之分,只有适不适合

前后端分离,是为了让前后端的职责更清晰,分工更合理高效,让合适的人做合适的事。
而你们的现状恰恰和前后端分离的初衷相悖!

再有就是 @娃娃脾气 说的 你得学会推卸不属于自己的责任 这个很重要

0

从技术角度来说,你们的项目经理太low了,保证安全问题是服务端最该考虑的问题,跑来质问前端?不是说前后端分离有多好,只是做技术的这么怼人真心没意思;
从人情世故来说,你还是要学会保护好自己,该站出来的时候不犹豫,不该你出头的时候还是要怂点。

0

东西没坏就别修,人心不齐就别干.
一个新成立的部门,未经项目经理同意,
就擅自向上级提议搞前后端分离,本来就有问题.
项目经理后来不爽也情有可原:项目明明跑得好好的,你们前端非要搞事情.
而且,前后端分离也不是万金油,不是什么地方都适合用.
以内容为主的,要求SEO的,显然需要后端渲染HTML.
以操作为主的,不需要SEO的,倒是可以让前端渲染HTML.
不过无论如何,从后端渲染切换到前端渲染,肯定要付出不少的修改成本,这点也不能忽视.

0

这样的项目经理我见多了。拘泥于自己掌握的那点知识,想吃一辈子老本!连数据安全只能由后端来保证,这么基础的问题都不知道。我也是醉了!直接告诉他:微软牛逼吧,操作系统就是个大前端,与用户直接交互的都是前端,还不是被破解了。前端代码是直接暴露给用户的,再怎么混淆都没用。还想保证安全?笑死我了...
直接怼回去,说得他脸红为止!搞技术的别考虑太多人情事故,我们就是跟电脑打交道的,直来直去比较好。想让我说话温柔点儿,对不起,我不是干客服的料。技术本来就要求严谨,真理面前人人平等!
怎么了,给再多钱,我干得不爽,照样不给你干。

0

这种问题提在知乎会好一些吧。。。

该答案已被忽略,原因:不符合答题规范 - 内容不是答案,可用评论、投票替代

-2

一句话不说,上去就是一锤子!

该答案已被忽略,原因:不符合答题规范 - 内容不是答案,可用评论、投票替代

撰写答案

推广链接