和前端小姐姐吵起来了

[activeliangg]

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

前端小姐姐：在一家有自己产品的半外包公司做了 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 个角色

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

[Jesmora]

不改告你性骚扰，肯定又是面试的适合要求造火箭了，不然不会遇到这种人才

[realpg]

这前端要是来我们公司 早开了...
拿着违约金赶紧滚...

[Foxalone]

给钱就干无所谓, 不要影响心情最重要. op 能力挺强的. 我之前也写过一段时间 ruby. 如果时间上不麻烦改了就是. 如果时间上影响到交付的话. 直接跟上面的人沟通, 他们愿意承担你就合理甩锅了, 并不是说怂. 跟这种人掰扯浪费时间.

[yanulg]

问题 1 找领导
问题 2 按交互，你的设计是你的事，前端没必要关心

[Shiaqiang]

@SwaggyMacro hhh 👍

[joinmouse]

不懂后端的前端很难成为一个好的前端，一般公司都应该是后端比前端更懂业务和有话语权吧

[Bluecoda]

典型的前端只会前端，不知道项目是怎么运作的

1 就是脑子抽了，明显数组更具有表达能力
2 我站后端，灵活性更好

所以我们公司新招的人，能写前端就写前端，前端如果觉得后端数据不好，就自己改，不会改就滚

以后招人都尽量招全栈，只会前端的很多人能力都很差，没有一个全局项目的认知。全栈的人就好很多，毕竟自己写后端+前端代码。

[drjames]

@ttyy22007 峰哥，是你吗

[nakun233]

前端换 AI

[HelloWorld23333]

协同问题，我还是喜欢一把梭，前端后端全干了啥事没有。我是支持后端能不做的逻辑都不做，把数据返回给前端就可以了。两边都能改=前端改。
按目前状态，你拉个群开个会。
1.让前端全力配合你 （不现实）
2.你全力配合前端
3.把前端挤兑走，你继续全栈
4.你接手一部分 vue ，数据处理好，前端再直接用。

[wgbx]

@ichou #97 这里说的高度复用是指前端组件，op 描述的场景最常见就是 Select 选择器，假设这个选择器是整个前端项目公用的组件，他只做传入一个值，返回一个值，（假设都是字符串数组进，字符串数组出）这个类型定义在项目初期已经确定了，里面的交互都是组件内部完成的，这个组件已经定义了接收是字符串数组，前端在这个场景要求后端按照这个规范来，完全是没有问题的，前端有没有办法处理，当然可以，在传入的时候转换传入或者在组件内部判断类型进行转换，但是这不是多此一举吗，历史包袱当然可以丢弃（但这个也不是包袱，只是标准不一样），但是按照整个项目的角度来说，这个事情在前期已有既定标准，这有什么争执的必要性呢？

结合 op 的描述，op 应该做过与之前公司既定规范不相符的事情，所以大家一边倒说前端有问题，是很难理解的，多写这一行就是舍近求远

[imtflin]

前端菜逼一个。

1. 坚决不能改，api 就要有明确清晰的返回，数组语义表达更正确，不能往丑了改。使用的 Vue 组件只支持 string ，前端转一下就行（这个组件估计也是垃圾组件）
2. 坚决不能改，最小的权限组合，更易于扩展。前端的看法短视且缺乏可维护性

[zhybb2010]

问题 1：肯定数组，字符串中万一再包含逗号，全体起立！
问题 2：你的更灵活，如果有成型的框架，应该你的是最优解；如果是稳定小项目，则前端的设计最简洁。

总结：让她滚。

[Meld]

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

第一条虽然我赞成你的观点，但是你也可以写个转换的逻辑，为转换的逻辑补一个单测就好了。

[sariya]

把“小姐姐”删掉吧，搞什么性别对立。不过就算删了应该还是站 op 的人多

[dssxzuxc]

@williamx #84
如果接受了“谁能力强谁改”这种做法，那整个团队的平均水平就会由水平最差的那个人决定，这也同时严重影响了开发舒适度和个人前景。
正确做法是让能力不足的人滚蛋，换个能正常写代码的人进来。
说实话这就他妈一行小学生水平破代码的事，写不出来的还他妈能叫程序员？
data.map(({ x, ...rest }) => ({ ...rest, x: x.join(',') }))
就算是树结构也就 10 行的事。
type Data = { x: number[]; children?: Data[] }
type Data1 = { x: string; children?: Data1[] }
const res: Data[] = []
const recursive = (nodes: Data[]): Data1[] =>
nodes.map(({ x, children, ...rest }) => ({
...rest,
x: x.join(','),
...(children && { children: recursive(children) }),
}))
const data = recursive(res)
而且这跟简单还是困难无关，这就是前端必须要做的事情，写 100 行也好 1000 行也好就应该在前端处理。那个用字符串绑定的弱智组件也应该换个给地球人使用的正常组件。

[tcper]

都是鸡毛蒜皮的事，整天折腾这些事，不如早点写完回家喝啤酒

[connor123]

我站你，不过你和她都是来上班的。所以我认为还是看上级的意思吧，上级让谁改谁就改，记住，代码是公司的，不是你个人的。

[quanmengli]

上一个老哥故意惯坏，然后让她以后给人吊

[tt0411]

问题一: 保持现有返回不变, 增加一个新字段, 不会 (也不应该) break 现有测试

问题二: 流程问题, 角色权限设计这么关键的模块, 难道没有详细设计文档?

[Tink]

第二个不好说，要看怎么设计的。

第一个正常来说必须得是数组，传 string 风险太大

[memcache]

如果这事有道理，就不需要摆资历

[yulon]

后端数据直接套前端组件的直接打死就完了，根本就不该这样

[ericguo]

楼主最大的问题是没有把前端的活一起干了，一个人全部干了就没有这样的烦恼了。

[Rehtt]

@wangtian2020 我们这边直接传时间戳

[wangtian2020]

@Rehtt 时间戳和 ISO 8601 字符串一样都是可以在全球任意位置确定准确的时间，相当于 Z 时区
毫秒时间戳的优点是兼容性极强
dayjs().format() —— '2025-08-08T08:46:56+08:00' ISO 8601 的优点是兼容性的同时有可读性

[ssh]

@Immortal 建议后端加个翻译器，毕竟不跟傻瓜论短长。
翻译器的名替你想好了，就叫(tfsg)TranslatorForStupidGirl ，给她自己用

[herang]

看错了，看成“和前端小姐姐搞起来了”，看来最近加班加太猛了，加到眼神恍惚了

[runlongyao2]

去学会说服别人，基于目前现状，尽量往工作量小的方向去调整，选择折中方案。另外不要把未来的不确定性做为谈判筹码。

[cjyiz]

作为一个前端，也觉得楼主的设计更好一点...这是小仙女本身的问题吧

[elmelloi]

换个实习生都比她强

[silence1corner]

问题二，对小程序来讲还真的可以这样，上小程序的角色业务基本不会变的，后端 api 做对应的角色控制就行，方便后续对改动限制。不要过度设计，跟不专业的人共事直接告诉她怎么做，多沟通两遍看她懂了没，然后自己自己去改。

[ichou]

@wgbx 单就前端让后端帮自己 join 这个操作，放哪儿都是站不住脚的。
你说复用，同一份数据在一个系统中尽量类型统一这是常识，GraphQL 能流行不是没有道理的。
你说 Select 选择器，那玩意儿叫通用组件，框架带的，用 1 万你的系统也称不上高度复用。

感觉你有点先站前端无罪，再射箭画靶的意思。
首先后端是已经上线的接口，其次前端 join 是常规操作，最后这个 join 放后端才是真正的脏代码，前端要渲染 Select 选择器叫后端 join ，那她要渲染编辑器又得让后端给数组，这不妥妥的技术债嘛。
不过，这种项目大概率也活不到关心技术债的时候

[webfamer]

都 agent 时代了，怎么还会有组件只支持 string 这种

[dwSun]

想办法征服她。。。物理上的征服，就没有问题了

[shebaoting]

我觉得问题不在于你。也不在于她，无论她的技术怎么样，她这样的性格和态度，决定了你很难在短时间内改变她的想法。

[shebaoting]

我觉得问题不在于你。也不在于她，无论她的技术怎么样，她这样的性格和态度，决定了你很难在短时间内改变她的想法。
问题在于，你们的开发约定流程和管理层级有问题。谁也不听谁的，就会有这样的问题产生。在企业内上班，其实很难达成谁对听谁的这样的和谐效果，因为大多数人觉得自己对的时候，很难让他觉得自己不对。教育任何一方都是浪费时间。这时候的问题不在于谁对谁错，而在于你们谁都不听谁的。如果当时领导决定了，你听这个前端的，那么，就算改成狗屎，你也必须得改，你不爽了你想解决办法，或者找上一级的领导谈，或者离职，或者忍受。问题的根本在于你们是平级，谁也不听谁的。

[Jannok]

就事论事，客观描述，楼主一口一个小姐姐，字里行间都透露着 ta 是煞笔的优越感，你是对的，也不会让人觉得你多厉害。

[withzhaoyu]

前端什么时候这么有话语权了？ 本前端从来就是后端给啥我用啥，就算返回的数据很复杂不好用也从来不吭声，有拉扯的那时间早改好了

[monosolo1on1]

首先我站楼主。

其次，这就是我宁愿做 indie 也不再想上班打工的原因之一。

明明还有那么多更重要的事情可以做，早点下班、多赚点钱、做喜欢做的事情...

[dongdong12345]

跟她讲：我们的目标是为了把项目做好，而不是为了省事。

[johnstonsmith]

前端还能指挥后端？服务它都来了

[xiaokinglong1]

这前端瞎搞啊

[HAYWAEL]

前端傻逼 ；但是 遇到这种人要想办法搞走她，或者不去接触她。不然就是你水平有问题

[accelerator1]

放我这边，早就开了，人菜话还多。

[enjoyCoding]

我偏前端一点, 之前和后端协作的时候一般会听后端的, 因为他们业务比我这切图的强多了, 脑子里想的东西也比我多多了, 我会问他们为啥这样干, 为啥不能像我说的那么干, 他们也会告诉我, 让我成长了不少

[pweng286]

第一个前端改
第二个如果产品确定以及肯定就四个角色写死就行的话,我是懒得写多余的,但是既然已经写出来了就问产品吧

[pweng286]

@drjames 弗洛伊峰

[1103409364]

我觉得无所谓，不管你什么数据都可以处理，只要数据类型，结构不要天天变就行。只怕后端数据结构变来变去的。这么多年我感觉，让后端保持数据结构稳定太难了，前端得写一堆 if 。经常出问题就让后端提供 dto 什么的，自己修复数据。

[erosripe]

问题一：说明前端妹子长得不够好看，养不了你的眼
问题二：前端能力不行

[seahorzhang]

能明显看出前端是在应付工作。她的想法是别人工作量多大我不管，我代码必须写的最少甚至不写。至于以后有什么改动或者不方便那是以后的事。

[uuundefined]

程序员不能走牛角尖路线，谁改不都一样。这种垃圾项目要毛的设计和可扩展性。
改不改主要就看小姐姐长的漂亮不漂亮就行了

[Katttes]

其一，前后端是平等的，不存在谁服务于谁，都是打工的，给谁俩呢？
其二，大多数改动都是根据项目情况来定的，像这种都经过测试的，肯定前端改合适。
其三，一个团队一定要有合作意识，有些东西一定要好好沟通，好好说话。
总结：做好自己，管我屁事。

[hefish]

我得看小姐姐的面相，看了才能决定是否支持她。

[meteora0tkvo]

写死角色非常不可取，哪怕牺牲点界面效果。以后领导/甲方改需求就老实了

[meteora0tkvo]

@meteora0tkvo 不过有可能是前端界面展示角色，各个角色有自己对应的 icon 和背景图片，你后端得加字段让这些元素能在后台配置。你们后端写接口只是对着需求文档来写的吧，有跟前端沟通过吗？

[xppgg]

应该是不好看

[n18255447846]

以前还会因为数据格式问题跟后端扯皮，规范一下都不愿意，现在都是笑看傻子后端瞎定义了

[M5tuA]

@sentinelK #67 哥，隔空更新下洗车吧。谢谢

[lilu0826]

本人 7 年狗前端，我一般都是前端能转换使用的数据不找后端改，除非那种我完全没法转换的数据格式了，再让后端帮忙处理一波，工作中比较讨厌 钻牛角尖的同事，还有钻进去了出不来的更烦。

[hoythan]

不用纠结，瞎逼写就行。拿几个钱啊还考虑维护。工资 2 万以内的都是屎山代码不用怀疑，2 万以上的属于屎珠穆朗玛峰。

[lilu0826]

@hoythan 赞同，怎么简单怎么来搞咯，项目和你总有一个能跑

[realkaiway]

我是前端，这波我站你 ，你司前端 5 年水平没法评价

[zepc007]

@sadj0aihnsdo 这种鲨臂你能下去吊吗

[CopyRight]

7 年后端和 5 年前端，都算是老油条了，还在为这种事情吵起来，不可思议。

[mozhizhu]

她咋不用 typescript 的理由来强制你返回 string ，，，，

直接跟负责人说明情况，他们要怎么弄就怎么改，明确后面再改等于加需求；这个问题，加钱就能解决

[ZeroDu]

你别说，有部分前端、客户端 只知道对象，不知道数组

[bugmaker233]

好看吗？有男朋友了吗？结婚了吗？😎

[yulgang]

好看不，好看就多交流，但是不改，不好看就不鸟她。

[lizy0329]

问题一 她是傻逼
问题二 你是傻逼

[lizy0329]

有些前端由于需要审核（客户端/小程序），更新等因素不好修改，很多工作是需要由后端来完成的，做到 数据驱动视图