V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
activeliangg
V2EX  ›  程序员

和前端小姐姐吵起来了

  •  
  •   activeliangg · 2025 年 8 月 7 日 · 19173 次点击
    这是一个创建于 157 天前的主题,其中的信息可能已经有所发展或是发生改变。

    最近在项目协作中和前端有些分歧,整理下情况,想请教大家怎么看。先简单交代下双方背景,避免断章取义:

    前端小姐姐:在一家有自己产品的半外包公司做了 5 年,主要做网页( Vue ),也偶尔协助小程序开发。

    我(后端):7 年自由野生全栈,一直是前后端独立项目开发,后端主力是 Ruby on Rails ,也写过 Node.js 、Vue 、小程序、爬虫、量化、脚本、Docker 、Android 插件、chrome 扩展程序等,属于遇到需求就学、全链路自己处理的那种。

    前端言论:

    • 你没有正经上过班没有和他人协作过都是自己闭门造车,我是多年老前端有协作经验,多听听我的意见
    • 产品经理最大,前端服务于产品,后端服务于前端,所以前端比后端大,后端应该多听前端,让改东西要配合。
    • 你的数据结构和一些机制和我们公司不一样,这让我很不习惯,开发得很难受。

    问题一:接口字段类型调整

    后端某接口已开发完毕,并通过自动化测试,现已部署上线。 前端提出一个变更请求:希望将接口返回字段从 ["a", "b"] 改为 "a,b"( Array → String ),理由是她使用的 Vue 组件只支持 string

    我当时建议:在提交接口前 split(',')一下 即可转换为数组,不必改接口结构。她坚持要后端改接口格式,当时项目是有点赶的。

    考虑到接口已经稳定并经过测试,这样的调整需要把相关的 n 个测试用例都变更重新测试和部署。

    请问在这种情况下,是否应该满足这样的修改请求?

    问题二:角色权限设计

    期间开发一款小程序,用户分为 4 类角色。我的后端做法是: 将权限拆成 8 个基础点(页面、功能级别),后台可自由配置角色权限,未来如需新增角色,配置即可,无需修改代码。

    前端做法是:根据 UI 图写死了 4 个角色及对应权限。认为后端接口不应该做成动态权限配置,理由是她们公司都是按固定角色方式来做。

    前端指出后端没按 UI 设计图的来,并建议后端也应该写死为 4 个角色

    但这个项目后期是我这边长期维护,不是短期外包,你更支持哪种做法?

    171 条回复    2025-08-26 14:58:54 +08:00
    1  2  
    luodan
        1
    luodan  
       2025 年 8 月 7 日   ❤️ 12
    找定接口的人,比如技术主管,项目经理。按接口定义做,相互不干涉。如果认为接口不合理,找定义接口的人反映,由定接口的人决定,而不是直接找另一方同级的低层沟通。
    yb2313
        2
    yb2313  
       2025 年 8 月 7 日   ❤️ 1
    猪圈里的猪还以被圈养为豪, 而且又是经典的前端基础功能都不愿意写, 告诉她能干就干, 不能干就滚, 看到这种没脑子还要指挥的人就烦
    Immortal
        3
    Immortal  
       2025 年 8 月 7 日   ❤️ 26
    这不是又菜又爱叫么...小仙女真是无孔不入
    ddddad
        4
    ddddad  
       2025 年 8 月 7 日
    @Immortal 属实是了,多清晰的语义,这波我站老哥
    yankebupt
        5
    yankebupt  
       2025 年 8 月 7 日
    1.谁改都行,交给AI。考虑到你这边有 unit test 的问题(全部重跑一遍再部署估计一天就没了)交给她改比较合适
    2.问问她改要几天工作量,能不能计入工作进度报告,能计入让她改吧。不能计入,问画图的那个人,写死了是为了安全考虑不,是的话,不改。然后以后加的时候,写入自己的工作量(甩锅给画图的)
    3231012
        6
    3231012  
       2025 年 8 月 7 日
    前后端难道不是平级?互补型打配合,如 1f 老哥说的,按公司的规定走,不清楚的地方直接向直属上级反映或者向公司负责相应板块的请教,避免同级之间争论,往往豪无意义。
    FlashEcho
        7
    FlashEcho  
       2025 年 8 月 7 日
    一确实是她改比较好

    二的话,你的方案相当于设计了 8 个更基础的角色?我感觉一个系统有哪些角色最好沿用老的,而不是有某个功能开发的时候又增加更细粒度的角色,除非功能确实有增加需要新角色

    一个角色有哪些权限,一个系统有哪些角色,基本上是不会变太多次的,在前端固定写死没什么问题

    角色就是一个中间层,没必要拆太细,拆太细那干嘛还要角色呢,直接给用户分配对哪些资源有权限就行了
    xuanbg
        8
    xuanbg  
       2025 年 8 月 7 日
    第一个,肯定要传数组
    第二个,没看明白你的设计是怎么回事,正确的做法是使用 RBAC 模型,通过给角色配置资源(页面上的功能、操作)来定义角色权限。根据你们的实际业务情况,你可以根据产品设计的要求预制 4 个角色。以后需要更多的角色或者需要用户自定义角色的权限,做个角色管理功能就行了。
    irisdev
        9
    irisdev  
       2025 年 8 月 7 日
    1.她的问题,数据结构确定下来不要改
    2.权限系统不是前端或者后端就能做的,按照你的设计前端路由表需最好你来维护,现在路由表肯定是在前端吧?两边开发之前没沟通好
    SwaggyMacro
        10
    SwaggyMacro  
       2025 年 8 月 7 日   ❤️ 9
    她是臭鲨臂
    tonytonychopper
        11
    tonytonychopper  
       2025 年 8 月 7 日 via iPhone
    我是前端,这种还是让前端自己改好,毕竟接口都上线了,改动可能会有兼容问题
    changepll
        12
    changepll  
       2025 年 8 月 7 日
    给护就改, 不给护就滚
    94
        13
    94  
       2025 年 8 月 7 日
    不是你的问题,考虑换前端开发。就背景言论 123 来说这不是一个所谓的“有协作经验的多年老前端”能说出来的话,更像是在 CPU 你 /🐶。

    -----
    问题 1 ,毫无疑问的前端问题前端处理。
    恕我直言“用 XXX 不支持 XXX 类型”作为理由的都是辣鸡。

    问题 2 ,不好说,但按照她描述的“传统”,基本上后端做调整是没跑了,多返回一个角色 KEY 去辅助前端做路由表的权鉴。
    看起来是因为如果把权限拆到功能级别,组装页面会相对复杂(如果是小程序),她不会处理。所以她的想法是类似于“一个角色固定一个页面功能”的方式。
    虽然也不是不能用,但是就没办法满足你对于未来的设计了,这个是需要和 PM 去确认未来对于权限管理的需求设计。
    那么在这个基础上,如果不想大吵的话,后端多加一个 [角色管理] 功能,前端按照登录用户的角色 KEY 去做路由是现阶段能解决问题的对策。然后考虑换人接她的盘。
    Geon97
        14
    Geon97  
       2025 年 8 月 7 日
    不如由 AI 全部接管
    iorilu
        15
    iorilu  
       2025 年 8 月 7 日
    短期肯定是前端改

    后端要不要改以后再说

    当然了, 她不改你可以帮她改
    wangtian2020
        16
    wangtian2020  
       2025 年 8 月 7 日   ❤️ 3
    鉴定为菜逼前端,后端提供的数据应该足够“原始”以能够处理成任何格式
    数组转逗号字符串简单,字符串分成数组时原始内容有逗号怎么办,应该极力避免字符串操作

    菜逼前后端检测题:后端传过来的时间格式带不带时区
    sadj0aihnsdo
        17
    sadj0aihnsdo  
       2025 年 8 月 7 日
    版本 T0 得用屌征服,不能用口,你懂的把?
    mizao
        18
    mizao  
       2025 年 8 月 7 日
    主包给的事件不全貌,不予评价!且主观意思居多
    nickytsui1862
        19
    nickytsui1862  
       2025 年 8 月 7 日
    @wangtian2020 客户端仔表示 第一个问题严重同意,内容传输格式是需要严谨的
    至于时间格式带不带时区的问题,个人观点是要标注解释好,起码写文档写个例子(毕竟不同格式有不同的解析方法)

    第二个问题,前端要做的是适配 4 个角色,后端多出的角色抛出不就好了,做个兜底。
    总的来说 这位前端是真的人菜脾气大
    zqguo
        20
    zqguo  
       2025 年 8 月 7 日
    我作为前端 leader ,这两个问题,如果是我,我会赞成你的做法。第一个问题:怎么简单怎么来,前端修改这个很快,而且你们接口已经经过完整的单元测试了,除非业务有问题,不然不建议动。第二:很简单的道理,考虑到后期维护,怎么方便怎么来。 但是整个开发流程我感觉缺少了前期的接口评审环节,不知道你们是否做了 ?
    thinkwei2012
        21
    thinkwei2012  
       2025 年 8 月 7 日
    在我们这儿一般这种问题是谁的能力强谁来改,后端能力强后端来改,前端能力强前端来改。

    当然,项目进度不赶的话,就找上级来定夺一下
    theprimone
        22
    theprimone  
       2025 年 8 月 7 日
    问题一就给我看傻了
    JoJoWuBeHumble
        23
    JoJoWuBeHumble  
       2025 年 8 月 7 日
    list 数据不要,要字符串自己分割,这是人能提的出来需求啊。
    你要是外部图表框架,要求按框架规定的数据结构返回数据我都能理解。
    怕不是她是把上家公司的轮子带过来,自己不会改,才叫你改的
    Mitt
        24
    Mitt  
       2025 年 8 月 7 日
    @chesha1 #7
    @xuanbg #8 我的理解第二个就是 RBAC ,本质前端还是可以 4 个角色,但每个角色还动态分有不同的权限(基础点)
    zihaoin1551
        25
    zihaoin1551  
       2025 年 8 月 7 日
    产品经理最大,前端服务于产品,后端服务于前端 —— 这句话不知道怎么得出来的。
    前后端不是两条并行的腿吗,哪儿存在前后脚一说?
    picone
        26
    picone  
       2025 年 8 月 7 日
    问题一:如果你以后换了个包后端是不是也得跟着重构呀
    interim
        27
    interim  
       2025 年 8 月 7 日
    问题一把我看傻了 +1
    MyFaith
        28
    MyFaith  
       2025 年 8 月 7 日
    什么臭傻逼
    1024potato
        29
    1024potato  
       2025 年 8 月 7 日
    问题一: 肯定要返回数组,数组类型更方便对数据进行二次处理(增删改查)。
    问题二: 你们两不存在对错,你的重点是扩展性,她的重点是简单,可以平衡下。
    你把需要的角色和权限数据在数据库配置好,然后自己调接口把返回的数据以文件给前端,这样前端没增加工作量,你又保证了扩展性。如果后期需要改动权限这块你再找前端沟通改成接口获取
    lx0758
        30
    lx0758  
       2025 年 8 月 7 日
    上一个后端把她舔舒服了
    salmon5
        31
    salmon5  
       2025 年 8 月 7 日
    说到前端,我不看内容,直接下定论:前端菜逼多,而且还不知道自己是菜逼
    jjx
        32
    jjx  
       2025 年 8 月 7 日
    我的原则是遵循原先的数据结构设计

    比方说后端数据结构是数组,就是数组,是字符串就是字符串

    除非前端太菜, 否则后端不做这种越俎代庖 事情
    xuwuruoshui
        33
    xuwuruoshui  
       2025 年 8 月 7 日
    太菜了
    robinchina
        34
    robinchina  
       2025 年 8 月 7 日
    我只全干·······支持改前端··能用数组用毛字符串啊········角色权限写死后面工作多得很····
    AccelerXu
        35
    AccelerXu  
       2025 年 8 月 7 日   ❤️ 1
    这波我站老哥.....这前端明显是被惯出来的.上一个后端对她太好了
    DonaldY
        36
    DonaldY  
       2025 年 8 月 7 日
    这种问题,一般都是能力强向下兼容,为了 deadline 和 少争吵,多做一些。
    EJW
        37
    EJW  
       2025 年 8 月 7 日
    干它就完了😡
    szdubinbin
        38
    szdubinbin  
       2025 年 8 月 7 日
    我算是知道为什么有些老接口是以一种莫名其妙格式返回的原因了 ,如果向上反馈和同级沟通不了你就躺平吧,当然为了后面的客户端还有其他正常前端觉得 “后端定的什么**接口”,我建议你加个参数如果传了返回数组
    jpyl0423
        39
    jpyl0423  
       2025 年 8 月 7 日
    什么菜鸡前端,不管从什么方面来讲肯定传数组啊
    way2create
        40
    way2create  
       2025 年 8 月 7 日
    “后端服务于前端,所以前端比后端大,后端应该多听前端,让改东西要配合” 如果这是原话那属实看笑了
    tabc2tgacd
        41
    tabc2tgacd  
       2025 年 8 月 7 日
    感觉这前端不专业,明显是她自己的问题。
    337136897
        42
    337136897  
       2025 年 8 月 7 日
    想个办法和前端小姐姐打一炮? 要让她对你服气
    sampeng
        43
    sampeng  
       2025 年 8 月 7 日 via iPhone
    你们 leader 呢? leader 这个时候装死?
    Zenon
        44
    Zenon  
       2025 年 8 月 7 日
    就不改,跟我上级说去吧
    jeasonzuo
        45
    jeasonzuo  
       2025 年 8 月 7 日
    1. 前端改比较合理,已经部署好的项目再修改字段格式不能保证兼容性
    2. 找技术主管,如果业务保证角色权限以后不会变(大概率是不可能的)那就不用做动态权限配置,既然是你长期维护,考虑业务需求,应该很好说服主管
    peng7534211
        46
    peng7534211  
       2025 年 8 月 7 日
    开技术评审,把接口文档写清楚,提前有疑问提出,过期按文档走,除非领导出面
    peng7534211
        47
    peng7534211  
       2025 年 8 月 7 日   ❤️ 1
    还要考虑这个领导跟前端小姐姐的关系,没关系,该怎么就怎么办
    irisdev
        48
    irisdev  
       2025 年 8 月 7 日   ❤️ 22
    一个技术+日常贴,四十条回复有四条硬往性上带,可见 v 站至少有 1/10 的煞笔
    yurenfeijing
        49
    yurenfeijing  
       2025 年 8 月 7 日
    我是前端,问题一毫无疑问肯定是前端改
    1. 你说这是一个变更请求,所以接口格式肯定提前跟她定好的
    2. 前端工作量不大,只要获取和保存的时候处理下就行了,热更新发布上线也更快,对客户造成的影响更小
    3. 后端可能涉及到落库问题,改格式可能要刷库
    4. 外包公司什么水平懂得都懂(就我接触过的几个而言)

    问题二看场景,SAAS 这种肯定是你这个动态权限配置,普通的小程序可能都没几个人用,怎么做都行,看产品经理怎么说
    journalistFromHK
        50
    journalistFromHK  
       2025 年 8 月 7 日   ❤️ 2
    你小子是不是故意黑我们前端的😡
    julio867
        51
    julio867  
       2025 年 8 月 7 日
    那个“前端言论”没有一条合理的,尤其是第 2 条,但凡在一个稍微正规的团队待过,都不会说出这种没有“见识”的话~
    至于前后端争论的“接口”问题,其实不应该是具体岗位的人在扯皮~
    就如很多评论说的,“接口契约”在开始前就应该由项目负责人开评审会确定下来,任何人都可以在会上提出自己的想法,最后由负责人拍板~
    visper
        52
    visper  
       2025 年 8 月 7 日
    第二个按你的。第一个大多数时候也按你的,除了一种很特别的情况:假如前端用了一套写得很差的封装比较死的前端组件,它一定是要值是豆号分开的。而她要改起来别人封装的组件很麻烦。那后端改一下也不是不可以。
    zhwithsweet
        53
    zhwithsweet  
       2025 年 8 月 7 日
    长的漂亮吗?
    THESDZ
        54
    THESDZ  
       2025 年 8 月 7 日   ❤️ 2
    针对双方语言逐条回复:

    你没有正经上过班没有和他人协作过都是自己闭门造车,我是多年老前端有协作经验,多听听我的意见
    > 没有任何因果关系,爹味发言

    产品经理最大,前端服务于产品,后端服务于前端,所以前端比后端大,后端应该多听前端,让改东西要配合。
    > 前端和后端均服务于产品,没有所谓后端服务于前端这种说法,强行因果关系

    你的数据结构和一些机制和我们公司不一样,这让我很不习惯,开发得很难受。
    > 数据结构就是数据结构,机制如果是标准形式,只看公司对于这些如何选型,跟“个人”习惯不习惯没有因果关系,按照这个说法,那我每个月没有拿 100w 的美刀,很难受,所以老板需要让着我?

    接口字段类型调整
    > 数据结构是对现实拙劣地模仿,现实世界明显数组,非要写 string 。菜

    角色权限设计
    > 具体的实现不该影响暴露的接口,这个地方不该暴露复杂度给外部,动态如果做了初始化其实就是静态,没必要争论对错,直接暴露出去的接口,给前端感知为静态即可(通过配置文件或者 sql 初始化)。多余地炫技。

    前端“小姐姐”
    > 性别在这其中没有任何的影响因素,不该提供这个信息。有“炒作”嫌疑

    以上只说出个人基于当前信息的下的判断。
    cocong
        55
    cocong  
       2025 年 8 月 7 日
    开发前没有讨论好吗?这些细枝末节的东西其实不是什么问题,开发前没沟通好才是最大的问题。
    SyncWorld
        56
    SyncWorld  
       2025 年 8 月 7 日
    我都不反驳,你让怎么改,怎么改,我不给自己添堵
    Chyen
        57
    Chyen  
       2025 年 8 月 7 日
    这么简单的东西前端自己转数组不就好了,我以前后端给我一堆 json ,我自己转成二维数组对象,转的的我真恶心。

    不过现在都有 ai 了,元数据丢给 ai 让它给你生成转成你要格式的数据不是 ez 吗?

    真羡慕现在工作的人,省去大量工作时间
    ardour
        58
    ardour  
       2025 年 8 月 7 日
    都不用看题主的背景交代,只看两个问题都把我看笑了。 典型的又懒又菜 🤣
    7inFen
        59
    7inFen  
       2025 年 8 月 7 日
    这是小仙女纯纯傻比
    ttyy22007
        60
    ttyy22007  
       2025 年 8 月 7 日   ❤️ 1
    @irisdev 屌丝们还是太 x 压抑了,有些人看到个女的不管啥事都能聊到下半身去
    dudubaba
        61
    dudubaba  
       2025 年 8 月 7 日   ❤️ 1
    所以有低级程序员和高级程序员之分,前端特别明显,都是转行的压根都不懂数据结构,只会傻瓜式拼接,一个 vue 至少提供了 70% 的前端岗位
    lscexpress
        62
    lscexpress  
       2025 年 8 月 7 日   ❤️ 2
    道理站你这边,但是我们站你这边没用。你想想怎么把工作快速做完,好早点下班吧。因为这个职场环境你多呆一会儿,寿命就要成倍减少,除非你血压低。
    Yjhenan
        63
    Yjhenan  
       2025 年 8 月 7 日
    还有专门要字符串的啊,我看见字符串就头大,数组这种原始数据多好用
    wukaige
        64
    wukaige  
       2025 年 8 月 7 日
    就不改
    sentinelK
        65
    sentinelK  
       2025 年 8 月 7 日
    这些不应该由你们来交流定义。
    产品和架构是干什么的?

    在信息不完全透明(需求,架构设计,扩展性考虑等)的情况下,讨论 API 的合理性与修改属于空中楼阁。
    m1ng
        66
    m1ng  
       2025 年 8 月 7 日
    把你们的分歧交给 AI ,让 AI 判断
    sentinelK
        67
    sentinelK  
       2025 年 8 月 7 日
    如果我司有这种情况:
    假如我是后端,我会让前端直接发 sql 。
    反之假如我是前端,我会让后端传本地渲染富文本。

    所以讨论这个没意义。
    GThui
        68
    GThui  
       2025 年 8 月 7 日
    说实话,从软件层面,考虑维护性,站你这边。同级沟通不了不要沟通,找上级沟通确定,因为她听不懂。
    kenshinhu
        69
    kenshinhu  
       2025 年 8 月 7 日
    这种情况我会要求把前端的 API 接口请求来看一下给他修改的代码吧,这里可以把前端的修改权限也入侵一下。
    以便了解一下前端的网络之后的接口再作适应。
    其实嘛~大家的目标都是一致的,获取方向不同
    这种自己消化就可,早点消化完早点下班。
    你也不想项目有问题出现时,都找所有技术来一遍排查处理吧
    xiangyuecn
        70
    xiangyuecn  
       2025 年 8 月 7 日
    产品经理 其实 跟开发部门基本可以说是毫无干系的😂

    爱管开发的产品经理一般是爱瞎指挥的傻屌😁
    Sentimental
        71
    Sentimental  
       2025 年 8 月 7 日
    正常开发流程来说,不应该双方先沟通好吗?各干各的,都按自己的想法来,最后对接的时候肯定是有出入的,双方都不愿意妥协,矛盾就产生了。
    你改变不了别人,作为上游,你可以主动跟前端提前沟通好,达成一致是主要目标,至于技术层面的考量,跟有些人说了也白说,讲不清,省点时间,早点把活做了,该干啥干啥
    cfer
        72
    cfer  
       2025 年 8 月 7 日
    说句不爱听的,看完你俩这背景,属于是卧龙遇见凤雏了。如果你们公司没有技术总监,全靠你俩商量的话。那还是早点开溜吧。
    jackding1208
        73
    jackding1208  
       2025 年 8 月 7 日
    不提性别这前端就是个彩笔
    rxswift
        74
    rxswift  
       2025 年 8 月 7 日
    beyound 的前端小姐姐
    pikes2023
        75
    pikes2023  
       2025 年 8 月 7 日
    服务端开发的时候,会和前端商量返回的字段结构吧,尤其第一次合作。前端明显改造一下就好了,可能是她不想改
    esee
        76
    esee  
       2025 年 8 月 7 日
    既然是公司团队多人协作,那应该有 leader ,功能设计接口定义怎么写肯定有规范,按照规范来就行了呗,比如你说的这个数据结构转换的问题,既然前期已经协商好了就没必要跟她吵啊,非要改那去提工单,只要给我算入工作量怎么都好说,一句话就想让我改那绝无可能。反正在我看来,双方都有问题,我遇到这种情况左耳朵进右耳朵出,随别人怎么说,只要需求提工单,再蠢的功能我绝不多说两句。最后,自己做东西做久了,会有一些习惯或者说强迫症,没必要纠结这些东西
    kakki
        77
    kakki  
       2025 年 8 月 7 日
    问题一
    她是傻逼

    问题二
    Role 通过约定命名定义,即可以是固定的也可以是动态的,毫无影响.
    digimoon
        78
    digimoon  
       2025 年 8 月 7 日
    你们不是先定好接口,然后前后端都按着接口文档开发的吗
    31415926535x
        79
    31415926535x  
       2025 年 8 月 7 日
    加个 bff 层的事(
    oom
        80
    oom  
       2025 年 8 月 7 日   ❤️ 1
    if 颜值不错 {

    } else {

    }
    woniu7
        81
    woniu7  
       2025 年 8 月 7 日   ❤️ 4
    波伏娃说了,让你改接口
    auhah
        82
    auhah  
       2025 年 8 月 7 日
    问题一 她是傻逼
    问题二 她是傻逼

    总结 她是傻逼
    dabennn
        83
    dabennn  
       2025 年 8 月 7 日
    先做方案设计和评审,这些问题都是在方案评审中讨论的。问题一前端做没有什么太大问题,问题二看产品已有设计和发展方向,要讨论也是和产品去讨论,功能层面沟通好再掰扯设计的事
    williamx
        84
    williamx  
       2025 年 8 月 7 日   ❤️ 1
    首先说结论:前端没有错。

    第一个问题,谁能力强谁改。前端不会,你非要叫她改,莫非你也不会?你加个接口调用原来的接口函数,把结果转换一下再给前端,并不费事,也不影响你所谓的测试。

    第二个问题,前端按照 UI 设计没有错,避免了过度设计。你后端追求灵活和可维护是你的事情,你给她的接口按固定角色方式就行了。你把灵活性丢给了前端,你考虑了她的能力没有?不是为了自己剩麻烦而给她找麻烦吗?我们后端的复杂和灵活的设计一定是要在接口层吞掉的,给到前端一定是简单好用的。
    googleaccount
        85
    googleaccount  
       2025 年 8 月 7 日
    好怕 她直接给你来女拳那一套
    wgbx
        86
    wgbx  
       2025 年 8 月 7 日
    发现大家无条件站队第一条,假设是这种情况,后端接口一下子 string 数组一下子 string 字符串,那这个事情就是后端没理了,前端组件已经高度复用,为什么非要针对这种情况为后端转数据结构呢?

    很多事情站各自角度都说说法,这种事情发帖正常,吵翻天就没必要了,前后端都是顺手的事情,工作中戾气太大天天骂这个骂那个也是没必要的
    EriczzZ
        87
    EriczzZ  
       2025 年 8 月 7 日
    joinString 干嘛的 这点破事还用改接口?
    BeforeTooLate
        88
    BeforeTooLate  
       2025 年 8 月 7 日
    碰到这种情况,应该向你的上级确认下,具体的标准到底是怎么样的,以后都按那套标准来就行了。完全不用 battle 了,没意义,因为完全说服不了前端就别浪费力气了
    softlight
        89
    softlight  
       2025 年 8 月 7 日
    这不手把手教的机会来了么
    Asuka0947
        90
    Asuka0947  
       2025 年 8 月 7 日
    我的话看给多少人天。(总人天-实际开发人天)/ 总人天 > 30% 勉强能干,>40%小爽,>50%必须能改啊。有的修改给到我这里,已经>200%了,必须大力狠狠地改 TM 的。
    McVander
        91
    McVander  
       2025 年 8 月 7 日
    问题 1:从长远性考虑,数组结构(原始结构)就是最适合的<前端问题>
    问题 2:前、后端的方案都可以用,但是后端的方案普适性更强。这个看业务短期业务其实都可以
    92Developer
        92
    92Developer  
       2025 年 8 月 7 日
    什么小姐姐,要么小姐,要么姐,哪那么多新奇的称谓,惯的毛病。
    IamUNICODE
        93
    IamUNICODE  
       2025 年 8 月 7 日
    第一个前端改
    第二个,贵司在做项目前不开会统筹设计前后端的吗?这什么脑残团队,震惊
    stanley0black
        94
    stanley0black  
       2025 年 8 月 7 日
    我是前端,你说的对。
    不会或者不了解后端开发模式的前端就是切图仔,没有发言权。
    hhhhkkk
        95
    hhhhkkk  
       2025 年 8 月 7 日
    @williamx 我现在的状态就是,对方只要说他不会(不管是能力方面还是态度方面的不会改),那就是我有问题,我就改。
    0x663
        96
    0x663  
       2025 年 8 月 7 日
    你俩谁是外包?谁是外包谁去改
    ichou
        97
    ichou  
       2025 年 8 月 7 日
    @wgbx 虽然,但是,同一个字段提交数组返回字符串,那这一个字段至少有两份类型定义了,这离“高度”复用偏得是不是有点远
    NjcyNzMzNDQ3
        98
    NjcyNzMzNDQ3  
       2025 年 8 月 7 日
    `前端言论` 一副高高在上没有一点尊重人的意思,就是惯的,就这沟通态度,无语
    hafuhafu
        99
    hafuhafu  
       2025 年 8 月 7 日
    这种一定要后端接口返回符合组件要的数据格式的真的是神人...这甚至不是偷懒的问题。
    edisonwong
        100
    edisonwong  
       2025 年 8 月 7 日
    1. join 的话里面有逗号咋整
    2. 脑子有坑啊,我要是前端巴不得权限控制全交给后端,后续新增角色就不用改前端了

    技术菜 + 高高在上 = sb
    1  2  
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   2255 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 34ms · UTC 01:25 · PVG 09:25 · LAX 17:25 · JFK 20:25
    ♥ Do have faith in what you're doing.