如题，我是公司新成立部门UEC的小前端，公司以前开发是用python的django开发的，项目经理习惯了前端只是写模板，后端拿来套的形式。不过去年年末，我的boss（uec的总监）向上级提议开始前后端分离的形式，于是招了很多个前端，准备把公司的产品一一做分离。
项目经理却觉得不靠谱，就各种问我这么保证这个安全，那个安全。。。。（最主要的是。。接口吧），由于我是小菜。。。对前后端分离也是一知半解，只知道前端通过接口调后端数据就行了。。。于是我就说数据接口的安全，前端是保证不了的，接口的安全需要后端来保证（不知道说得对不对，但是前端的确没法保证这个的安全啊。。。），当时可能回答的比较急。。项目经理就火了。。就说“你们这是瞎搞，我不管，我们这边已经做得很好了，问题都在你们那边，你们UEC部门存在的意义就有问题”，看他这样，我也就不敢反驳什么了，当时产品还给我解了围（他原来也是搞技术的），跟项目经理说：“接口安全的确是后端的活，我以前做过的.........”【此处省略】。
自此以后，项目经理就各种看我不顺眼，本来该后端处理的数据，直接让他的人粗枝大叶的甩给我让我在前端处理【上千条数据。。就在前端 搜索。。排序 不知算不算多】。然后怪我做的慢，要是前后端不分离项目早做完了，我那个委屈啊?，本来这个项目我来的时候就延期了，当时这个项目还没有后端，我提前把前端部分做完了，等着他们调后端过来，就等了半个月（期间 我去了别的项目 帮别的前端），后端来了，数据调好了，产品在年前那一周又改需求。。。设计不得不赶紧设计，我不得不等设计完继续改页面，增加功能，所以年前没做完，到了年后这周五才做完。。。。，这怪我吗？？？ 怎么延期的锅就这么甩给我了？？
前后端分离了，后端只管数据的事了，只管M层了，所以后端做得快了，VC层前端来做，反倒是他觉得他的后端做得很快了，我们前端拖了项目的后腿。。。 我咋办。。。。我都觉得哔了狗了。。。 已经向我的boss反应了情况（boss是前后端分离的推动者，但是他是设计出身?可能在技术面前话语权 没那么重)，心里面还是觉得有点瘆得慌，我在试用期啊。。真怕被刷了。。，我该怎么做，好迷茫。。
我觉得你们项目经理出发点没多大错，如果他是以整个项目的高度来看问题的话，而且搞技术的都有点儿这个...但是后来怼你太过分了。
你自己也说了对前后端分离一知半解，所以如果你想尝试需要团队支持，至少有个扛把子去推动，另外别把自己局限在前端这个范围了。
这几年前端非常火，火到很多人转了前端（我就是其中之一），以我自己的经验，前后端分离没有想象中那么美好，得挑合适的项目，有时候特别坑爹，前端会很累。而且现在前后端分离的概念比较模糊，如果不懂后端，绝逼是个大坑。
甚至我有一种感觉，从我进入行业开始一直就在说解耦，事实上web开发本来就是一体的，很容易进入为了解耦而解耦的误区，现在有一些方案的趋势又走向了反方向，三十年河东三十年河西。所以有时候看到一些特别老的技术方案，有种旧瓶装新酒的感觉。
如果你真是个小前端，这个事你就别主动推了，真想要尝试前后端分离，等待机会换个项目，或者换个公司。
我比较赞同 @娃娃脾气 的观点。不过这里我不说怎么做人，我准备从技术和管理的角度来说说
首先，我对我带过的所有人都说过一句话：永远不要相信前端。不是说不要相信前端工程师，而是说不要相信前端提交的数据，换句话说，安全性肯定是后端的事情。
前后分离是必然趋势，考虑一个问题，你愿意后端渲染页面还是前端渲染页面？假设后端渲染页面平均需要 0.1 秒，前端渲染平均需要 2 秒，20 倍的差距。但是假如有 100 个用户，后端需要花 10 秒来处理，如果阻塞的话，平均个用户要等 5 秒；而前端渲染，每个用户只需要等 2 秒。所以从性能上来说，我个人是比较推荐将页面处理过程前移的。目前各种静态化趋势也在证明这一点。
其次，从设计的角度来说，前后分离可以实现呈现和数据(逻辑)的解耦，这也是一种 SOA 的思想。后端可以专注于处理逻辑和数据，把呈现的事情完全交给前端处理。前后端只需要约定好数据接口(通常是一定格式的 JSON 或 XML)，剩下的事情就是各干个的，互不影响；不仅前后端的开发轻松，测试也轻松，测前端可以做桩，测后端可以直接验证数据；如果客户对界面不满意，后端可以去休假，前端照新设计把样式表一换就能解决；如果是对用户体验不满意，前端脚本要做的事情就多一点……不过大部分都有框架实现。换句话说，前后分离大大减轻了后端的工作量，但前端工程师一定要顶得起。
接下来就是分工的事情。任何事情，只要是多人(或一人多角色也是同样)合作，就肯定存在分工的问题。分工，说白了就是职责，责任分不清楚，扯皮是迟早的事情。前后分离，从哪里分，分到啥程度，这些都需要预先做好约定，把责任划分清楚。就拿数据来说，几千条数据是应该前端处理的还是应该后端处理的？就按一条数据 1K 来算，几千条也不过就几 M，其实前端处理后端处理都可以。后端处理肯定快得多，而且有缓存优势，并不会造成多大的阻塞，而前端处理除了加载数据慢一点，内存消耗大一点，也不是多大的问题(没人会把几千条数据同时渲染出来吧)，那这个就要靠约定了，而约定也不是随便约的，要架构师说话，要不然架构师拿来干啥。架构师认为这地方，前端处理用户体验不好，分给后端处理，前端传参，后端把数据过滤后给出来，那就后端处理；架构师认为这地方前端处理无压力，后端是瓶颈，那就前端处理……分清楚了，自然不会扯皮。
如果前端压力过大，后端轻松得不行，那就是项目经理要负责的事情了，这很明显是人力资源安排不合理。就按前后各占 50% 工作量来说，1 个前端对 3 个后端(举例)就是很不合适的安排。而且前后分离之后，很明显后期前端工作量会比后端大得多，所以在不同的项目时期，人力资源如何安排，这是项目经理要干的事情。项目经理要做的事情就是协调好资源，控制好风险，把握好进度，再尽可能的少花钱——我一向不太赞成技术人员做项目经理，做技术和做项目管理思维方式都不一样。
总的来说呢，前后分离不是罪，架构师、项目经理、项目组各成员各司其职，尽量以契约的精神来办事，事情就好办得多。如果你现在认为跟项目经理沟通不下去，找你的上司去沟通，还是沟通不下去，再找更上一级的上司……如果怎么都沟通这不下去，那就没有合作的可能，留着也难受，还不如换个地方发展(如果你只是考虑生存，那就忍吧)。
鄂公网安备 42090202000075号 - 鄂ICP备2021002952号-1
微博登录
QQ登录
微信扫码登录
