• 和前端小姐姐吵起来了,大家怎么看?
  • 发布于 3天前
  • 39 热度
    12 评论
  • 冰魄
  • 0 粉丝 58 篇博客
  •   
最近在项目协作中和前端有些分歧,整理下情况,想请教大家怎么看。先简单交代下双方背景,避免断章取义:
前端小姐姐:在一家有自己产品的半外包公司做了 5 年,主要做网页( Vue ),也偶尔协助小程序开发。
我(后端):7 年自由野生全栈,一直是前后端独立项目开发,后端主力是 Ruby on Rails ,也写过 Node.js 、Vue 、小程序、爬虫、量化、脚本、Docker 、Android 插件、chrome 扩展程序等,属于遇到需求就学、全链路自己处理的那种。

前端言论:
1.你没有正经上过班没有和他人协作过都是自己闭门造车,我是多年老前端有协作经验,多听听我的意见
2.产品经理最大,前端服务于产品,后端服务于前端,所以前端比后端大,后端应该多听前端,让改东西要配合。

3.你的数据结构和一些机制和我们公司不一样,这让我很不习惯,开发得很难受。


问题一:接口字段类型调整
后端某接口已开发完毕,并通过自动化测试,现已部署上线。 前端提出一个变更请求:希望将接口返回字段从 ["a", "b"] 改为 "a,b"( Array → String ),理由是她使用的 Vue 组件只支持 string 。
我当时建议:在提交接口前 split(',')一下 即可转换为数组,不必改接口结构。她坚持要后端改接口格式,当时项目是有点赶的。
考虑到接口已经稳定并经过测试,这样的调整需要把相关的 n 个测试用例都变更重新测试和部署。请问在这种情况下,是否应该满足这样的修改请求?

问题二:角色权限设计
期间开发一款小程序,用户分为 4 类角色。我的后端做法是: 将权限拆成 8 个基础点(页面、功能级别),后台可自由配置角色权限,未来如需新增角色,配置即可,无需修改代码。
前端做法是:根据 UI 图写死了 4 个角色及对应权限。认为后端接口不应该做成动态权限配置,理由是她们公司都是按固定角色方式来做。
前端指出后端没按 UI 设计图的来,并建议后端也应该写死为 4 个角色
但这个项目后期是我这边长期维护,不是短期外包,你更支持哪种做法?
用户评论
  • 黄月英
  • 我作为前端 leader ,这两个问题,如果是我,我会赞成你的做法。第一个问题:怎么简单怎么来,前端修改这个很快,而且你们接口已经经过完整的单元测试了,除非业务有问题,不然不建议动。第二:很简单的道理,考虑到后期维护,怎么方便怎么来。 但是整个开发流程我感觉缺少了前期的接口评审环节,不知道你们是否做了 ?
  • 2025/8/9 13:01:00 [ 0 ] [ 0 ] 回复
  • 回忆经典
  • 鉴定为菜逼前端,后端提供的数据应该足够“原始”以能够处理成任何格式,数组转逗号字符串简单,字符串分成数组时原始内容有逗号怎么办,应该极力避免字符串操作,菜逼前后端检测题:后端传过来的时间格式带不带时区。
  • 2025/8/9 12:57:00 [ 0 ] [ 0 ] 回复
  • CEBBCt
  • 不是你的问题,考虑换前端开发。就背景言论 123 来说这不是一个所谓的“有协作经验的多年老前端”能说出来的话,更像是在 CPU 你 /🐶。
    -----
    问题 1 ,毫无疑问的前端问题前端处理。
    恕我直言“用 XXX 不支持 XXX 类型”作为理由的都是辣鸡。
    问题 2 ,不好说,但按照她描述的“传统”,基本上后端做调整是没跑了,多返回一个角色 KEY 去辅助前端做路由表的权鉴。
    看起来是因为如果把权限拆到功能级别,组装页面会相对复杂(如果是小程序),她不会处理。所以她的想法是类似于“一个角色固定一个页面功能”的方式。
    虽然也不是不能用,但是就没办法满足你对于未来的设计了,这个是需要和 PM 去确认未来对于权限管理的需求设计。
    那么在这个基础上,如果不想大吵的话,后端多加一个 [角色管理] 功能,前端按照登录用户的角色 KEY 去做路由是现阶段能解决问题的对策。然后考虑换人接她的盘。
  • 2025/8/9 12:35:00 [ 0 ] [ 0 ] 回复
  • BruceLe
  • 1.她的问题,数据结构确定下来不要改
    2.权限系统不是前端或者后端就能做的,按照你的设计前端路由表需最好你来维护,现在路由表肯定是在前端吧?两边开发之前没沟通好
  • 2025/8/9 12:21:00 [ 0 ] [ 0 ] 回复
  • Dock
  • 第一个,肯定要传数组
    第二个,没看明白你的设计是怎么回事,正确的做法是使用 RBAC 模型,通过给角色配置资源(页面上的功能、操作)来定义角色权限。根据你们的实际业务情况,你可以根据产品设计的要求预制 4 个角色。以后需要更多的角色或者需要用户自定义角色的权限,做个角色管理功能就行了。
  • 2025/8/9 11:40:00 [ 0 ] [ 0 ] 回复
  • Jeff
  • 一确实是她改比较好
    二的话,你的方案相当于设计了 8 个更基础的角色?我感觉一个系统有哪些角色最好沿用老的,而不是有某个功能开发的时候又增加更细粒度的角色,除非功能确实有增加需要新角色

    一个角色有哪些权限,一个系统有哪些角色,基本上是不会变太多次的,在前端固定写死没什么问题。角色就是一个中间层,没必要拆太细,拆太细那干嘛还要角色呢,直接给用户分配对哪些资源有权限就行了。
  • 2025/8/9 11:33:00 [ 0 ] [ 0 ] 回复
  • Fayer
  • 1.谁改都行,交给AI。考虑到你这边有 unit test 的问题(全部重跑一遍再部署估计一天就没了)交给她改比较合适
    2.问问她改要几天工作量,能不能计入工作进度报告,能计入让她改吧。不能计入,问画图的那个人,写死了是为了安全考虑不,是的话,不改。然后以后加的时候,写入自己的工作量(甩锅给画图的)
  • 2025/8/9 11:28:00 [ 0 ] [ 0 ] 回复
  • 夜灵霜影
  • 猪圈里的猪还以被圈养为豪, 而且又是经典的前端基础功能都不愿意写, 告诉她能干就干, 不能干就滚, 看到这种没脑子还要指挥的人就烦
  • 2025/8/9 11:24:00 [ 0 ] [ 0 ] 回复
  • 我没那么帅
  • 找定接口的人,比如技术主管,项目经理。按接口定义做,相互不干涉。如果认为接口不合理,找定义接口的人反映,由定接口的人决定,而不是直接找另一方同级的低层沟通。
  • 2025/8/9 11:21:00 [ 0 ] [ 0 ] 回复