javascript - 公司项目首次尝试前后端分离，结果项目经理（技术）各种怼我，咋办？

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

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

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

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

是个不错的话题，适合在知乎上唠嗑！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

引用作者原话: boss是前后端分离的推动者，但是他是设计出身

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

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

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

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

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

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

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

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

哈哈，这种问题，不要怂，这样处理～

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

举个栗子：

• 他：前后端不安全

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

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

• 你：前后端不分离就安全了吗？

• 他：...

• 你：...

哈哈～

补充：管它前后端分离不分离，前端都是永远不可信的；分离只是为了解耦；

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

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

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

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

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

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

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

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

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

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

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

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

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

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