这是一个创建于 193 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在项目协作中和前端有些分歧，整理下情况，想请教大家怎么看。先简单交代下双方背景，避免断章取义：
前端小姐姐：在一家有自己产品的半外包公司做了 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 个角色
但这个项目后期是我这边长期维护，不是短期外包，你更支持哪种做法？
 |
101
Jesmora 2025 年 8 月 7 日  1
不改告你性骚扰，肯定又是面试的适合要求造火箭了，不然不会遇到这种人才
|
 |
102
realpg PRO 这前端要是来我们公司 早开了...
拿着违约金赶紧滚... |
 |
103
Foxalone 2025 年 8 月 7 日
给钱就干无所谓, 不要影响心情最重要. op 能力挺强的. 我之前也写过一段时间 ruby. 如果时间上不麻烦改了就是. 如果时间上影响到交付的话. 直接跟上面的人沟通, 他们愿意承担你就合理甩锅了, 并不是说怂. 跟这种人掰扯浪费时间.
|
 |
104
yanulg 2025 年 8 月 7 日
问题 1 找领导
问题 2 按交互，你的设计是你的事，前端没必要关心 |
 |
105
Shiaqiang 2025 年 8 月 7 日
@SwaggyMacro hhh 👍
|
 |
106
joinmouse 2025 年 8 月 7 日
不懂后端的前端很难成为一个好的前端，一般公司都应该是后端比前端更懂业务和有话语权吧
|
 |
107
Bluecoda 2025 年 8 月 7 日
典型的前端只会前端，不知道项目是怎么运作的
1 就是脑子抽了，明显数组更具有表达能力 2 我站后端，灵活性更好 所以我们公司新招的人，能写前端就写前端，前端如果觉得后端数据不好，就自己改，不会改就滚 以后招人都尽量招全栈，只会前端的很多人能力都很差，没有一个全局项目的认知。全栈的人就好很多，毕竟自己写后端+前端代码。 |
 |
109
nakun233 2025 年 8 月 7 日
前端换 AI
|
 |
110
HelloWorld23333 2025 年 8 月 7 日
协同问题，我还是喜欢一把梭，前端后端全干了啥事没有。我是支持后端能不做的逻辑都不做，把数据返回给前端就可以了。两边都能改=前端改。
按目前状态，你拉个群开个会。 1.让前端全力配合你 （不现实） 2.你全力配合前端 3.把前端挤兑走，你继续全栈 4.你接手一部分 vue ，数据处理好，前端再直接用。 |
 |
111
wgbx 2025 年 8 月 7 日
@ichou #97 这里说的高度复用是指前端组件，op 描述的场景最常见就是 Select 选择器，假设这个选择器是整个前端项目公用的组件，他只做传入一个值，返回一个值，（假设都是字符串数组进，字符串数组出）这个类型定义在项目初期已经确定了，里面的交互都是组件内部完成的，这个组件已经定义了接收是字符串数组，前端在这个场景要求后端按照这个规范来，完全是没有问题的，前端有没有办法处理，当然可以，在传入的时候转换传入或者在组件内部判断类型进行转换，但是这不是多此一举吗，历史包袱当然可以丢弃（但这个也不是包袱，只是标准不一样），但是按照整个项目的角度来说，这个事情在前期已有既定标准，这有什么争执的必要性呢？
结合 op 的描述，op 应该做过与之前公司既定规范不相符的事情，所以大家一边倒说前端有问题，是很难理解的，多写这一行就是舍近求远 |
 |
112
imtflin 2025 年 8 月 7 日
前端菜逼一个。
1. 坚决不能改，api 就要有明确清晰的返回，数组语义表达更正确，不能往丑了改。使用的 Vue 组件只支持 string ，前端转一下就行（这个组件估计也是垃圾组件） 2. 坚决不能改，最小的权限组合，更易于扩展。前端的看法短视且缺乏可维护性 |
 |
113
zhybb2010 2025 年 8 月 7 日
问题 1：肯定数组，字符串中万一再包含逗号，全体起立！
问题 2：你的更灵活，如果有成型的框架，应该你的是最优解；如果是稳定小项目，则前端的设计最简洁。 总结：让她滚。 |
 |
114
Rat3 2025 年 8 月 7 日
考虑到接口已经稳定并经过测试，这样的调整需要把相关的 n 个测试用例都变更重新测试和部署。
第一条虽然我赞成你的观点，但是你也可以写个转换的逻辑，为转换的逻辑补一个单测就好了。 |
 |
115
sariya 2025 年 8 月 7 日
把“小姐姐”删掉吧，搞什么性别对立。不过就算删了应该还是站 op 的人多
|
 |
116
Ketteiron 2025 年 8 月 7 日
@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 行也好就应该在前端处理。那个用字符串绑定的弱智组件也应该换个给地球人使用的正常组件。 |
 |
117
tcper 2025 年 8 月 7 日 1
都是鸡毛蒜皮的事，整天折腾这些事，不如早点写完回家喝啤酒
|
 |
118
connor123 2025 年 8 月 7 日
我站你，不过你和她都是来上班的。所以我认为还是看上级的意思吧，上级让谁改谁就改，记住，代码是公司的，不是你个人的。
|
 |
119
quanmengli 2025 年 8 月 7 日
上一个老哥故意惯坏，然后让她以后给人吊
|
 |
120
tt0411 2025 年 8 月 8 日
问题一: 保持现有返回不变, 增加一个新字段, 不会 (也不应该) break 现有测试
问题二: 流程问题, 角色权限设计这么关键的模块, 难道没有详细设计文档? |
 |
121
Tink PRO 第二个不好说，要看怎么设计的。
第一个正常来说必须得是数组，传 string 风险太大 |
 |
122
memcache 2025 年 8 月 8 日
如果这事有道理，就不需要摆资历
|
 |
123
yulon 2025 年 8 月 8 日
后端数据直接套前端组件的直接打死就完了，根本就不该这样
|
 |
124
ericguo 2025 年 8 月 8 日
楼主最大的问题是没有把前端的活一起干了，一个人全部干了就没有这样的烦恼了。
|
 |
125
Rehtt 2025 年 8 月 8 日
@wangtian2020 我们这边直接传时间戳
|
 |
126
wangtian2020 2025 年 8 月 8 日
@Rehtt 时间戳和 ISO 8601 字符串一样都是可以在全球任意位置确定准确的时间，相当于 Z 时区
毫秒时间戳的优点是兼容性极强 dayjs().format() —— '2025-08-08T08:46:56+08:00' ISO 8601 的优点是兼容性的同时有可读性 |
 |
127
ssh 2025 年 8 月 8 日
@Immortal 建议后端加个翻译器，毕竟不跟傻瓜论短长。
翻译器的名替你想好了，就叫(tfsg)TranslatorForStupidGirl ，给她自己用 |
 |
128
herang 2025 年 8 月 8 日
看错了，看成“和前端小姐姐搞起来了”，看来最近加班加太猛了，加到眼神恍惚了
|
 |
129
runlongyao2 2025 年 8 月 8 日
去学会说服别人，基于目前现状，尽量往工作量小的方向去调整，选择折中方案。另外不要把未来的不确定性做为谈判筹码。
|
 |
130
cjyiz 2025 年 8 月 8 日
作为一个前端，也觉得楼主的设计更好一点...这是小仙女本身的问题吧
|
 |
131
elmelloi 2025 年 8 月 8 日
换个实习生都比她强
|
 |
132
silence1corner 2025 年 8 月 8 日
问题二，对小程序来讲还真的可以这样，上小程序的角色业务基本不会变的，后端 api 做对应的角色控制就行，方便后续对改动限制。不要过度设计，跟不专业的人共事直接告诉她怎么做，多沟通两遍看她懂了没，然后自己自己去改。
|
 |
133
ichou 2025 年 8 月 8 日
@wgbx 单就前端让后端帮自己 join 这个操作，放哪儿都是站不住脚的。
你说复用，同一份数据在一个系统中尽量类型统一这是常识，GraphQL 能流行不是没有道理的。 你说 Select 选择器，那玩意儿叫通用组件，框架带的，用 1 万你的系统也称不上高度复用。 感觉你有点先站前端无罪，再射箭画靶的意思。 首先后端是已经上线的接口，其次前端 join 是常规操作，最后这个 join 放后端才是真正的脏代码，前端要渲染 Select 选择器叫后端 join ，那她要渲染编辑器又得让后端给数组，这不妥妥的技术债嘛。 不过，这种项目大概率也活不到关心技术债的时候 |
 |
134
webfamer 2025 年 8 月 8 日
都 agent 时代了，怎么还会有组件只支持 string 这种
|
 |
135
dwSun 2025 年 8 月 8 日
 想办法征服她。。。物理上的征服，就没有问题了 |
 |
136
shebaoting 2025 年 8 月 8 日
我觉得问题不在于你。也不在于她，无论她的技术怎么样，她这样的性格和态度，决定了你很难在短时间内改变她的想法。
|
|
137
shebaoting 2025 年 8 月 8 日
我觉得问题不在于你。也不在于她，无论她的技术怎么样，她这样的性格和态度，决定了你很难在短时间内改变她的想法。
问题在于，你们的开发约定流程和管理层级有问题。谁也不听谁的，就会有这样的问题产生。在企业内上班，其实很难达成谁对听谁的这样的和谐效果，因为大多数人觉得自己对的时候，很难让他觉得自己不对。教育任何一方都是浪费时间。这时候的问题不在于谁对谁错，而在于你们谁都不听谁的。如果当时领导决定了，你听这个前端的，那么，就算改成狗屎，你也必须得改，你不爽了你想解决办法，或者找上一级的领导谈，或者离职，或者忍受。问题的根本在于你们是平级，谁也不听谁的。 |
 |
138
Jannok 2025 年 8 月 8 日
就事论事，客观描述，楼主一口一个小姐姐，字里行间都透露着 ta 是煞笔的优越感，你是对的，也不会让人觉得你多厉害。
|
 |
139
withzhaoyu 2025 年 8 月 8 日
前端什么时候这么有话语权了？ 本前端从来就是后端给啥我用啥，就算返回的数据很复杂不好用也从来不吭声，有拉扯的那时间早改好了
|
 |
140
monosolo1on1 2025 年 8 月 8 日 via iPhone
首先我站楼主。
其次，这就是我宁愿做 indie 也不再想上班打工的原因之一。 明明还有那么多更重要的事情可以做，早点下班、多赚点钱、做喜欢做的事情... |
 |
141
dongdong12345 2025 年 8 月 8 日
跟她讲：我们的目标是为了把项目做好，而不是为了省事。
|
 |
142
johnstonsmith 2025 年 8 月 8 日
前端还能指挥后端？服务它都来了
|
 |
143
xiaokinglong1 2025 年 8 月 8 日
这前端瞎搞啊
|
 |
144
HAYWAEL 2025 年 8 月 8 日
前端傻逼 ；但是 遇到这种人要想办法搞走她，或者不去接触她。不然就是你水平有问题
|
 |
145
accelerator1 2025 年 8 月 8 日
放我这边，早就开了，人菜话还多。
|
 |
146
enjoyCoding 2025 年 8 月 8 日
我偏前端一点, 之前和后端协作的时候一般会听后端的, 因为他们业务比我这切图的强多了, 脑子里想的东西也比我多多了, 我会问他们为啥这样干, 为啥不能像我说的那么干, 他们也会告诉我, 让我成长了不少
|
 |
147
pweng286 2025 年 8 月 8 日
第一个前端改
第二个如果产品确定以及肯定就四个角色写死就行的话,我是懒得写多余的,但是既然已经写出来了就问产品吧 |
 |
149
1103409364 2025 年 8 月 9 日
我觉得无所谓，不管你什么数据都可以处理，只要数据类型，结构不要天天变就行。只怕后端数据结构变来变去的。这么多年我感觉，让后端保持数据结构稳定太难了，前端得写一堆 if 。经常出问题就让后端提供 dto 什么的，自己修复数据。
|
 |
150
erosripe 2025 年 8 月 9 日
问题一：说明前端妹子长得不够好看，养不了你的眼
问题二：前端能力不行 |
 |
151
seahorzhang 2025 年 8 月 9 日
能明显看出前端是在应付工作。她的想法是别人工作量多大我不管，我代码必须写的最少甚至不写。至于以后有什么改动或者不方便那是以后的事。
|
 |
152
uuundefined 2025 年 8 月 9 日
程序员不能走牛角尖路线，谁改不都一样。这种垃圾项目要毛的设计和可扩展性。
改不改主要就看小姐姐长的漂亮不漂亮就行了 |
 |
153
Katttes 2025 年 8 月 9 日
其一，前后端是平等的，不存在谁服务于谁，都是打工的，给谁俩呢？
其二，大多数改动都是根据项目情况来定的，像这种都经过测试的，肯定前端改合适。 其三，一个团队一定要有合作意识，有些东西一定要好好沟通，好好说话。 总结：做好自己，管我屁事。 |
 |
154
hefish 2025 年 8 月 10 日
我得看小姐姐的面相，看了才能决定是否支持她。
|
 |
155
meteora0tkvo 2025 年 8 月 11 日
写死角色非常不可取，哪怕牺牲点界面效果。以后领导/甲方改需求就老实了
|
|
156
meteora0tkvo 2025 年 8 月 11 日
@meteora0tkvo 不过有可能是前端界面展示角色，各个角色有自己对应的 icon 和背景图片，你后端得加字段让这些元素能在后台配置。你们后端写接口只是对着需求文档来写的吧，有跟前端沟通过吗？
|
 |
157
xppgg 2025 年 8 月 11 日
应该是不好看
|
 |
158
n18255447846 2025 年 8 月 11 日
以前还会因为数据格式问题跟后端扯皮，规范一下都不愿意，现在都是笑看傻子后端瞎定义了
|
 |
160
lilu0826 2025 年 8 月 11 日
本人 7 年狗前端，我一般都是前端能转换使用的数据不找后端改，除非那种我完全没法转换的数据格式了，再让后端帮忙处理一波，工作中比较讨厌 钻牛角尖的同事，还有钻进去了出不来的更烦。
|
 |
161
hoythan 2025 年 8 月 11 日
不用纠结，瞎逼写就行。拿几个钱啊还考虑维护。工资 2 万以内的都是屎山代码不用怀疑，2 万以上的属于屎珠穆朗玛峰。
|
 |
163
realkaiway 2025 年 8 月 11 日
我是前端，这波我站你
，你司前端 5 年水平没法评价 |
 |
164
zepc007 2025 年 8 月 11 日
@sadj0aihnsdo 这种鲨臂你能下去吊吗
|
 |
165
CopyRight 2025 年 8 月 11 日 via iPhone
7 年后端和 5 年前端，都算是老油条了，还在为这种事情吵起来，不可思议。
|
 |
166
mozhizhu 2025 年 8 月 11 日
她咋不用 typescript 的理由来强制你返回 string ，，，，
直接跟负责人说明情况，他们要怎么弄就怎么改，明确后面再改等于加需求；这个问题，加钱就能解决 |
 |
167
ZeroDu 2025 年 8 月 12 日
你别说，有部分前端、客户端 只知道对象，不知道数组
 |
 |
168
bugmaker233 2025 年 8 月 12 日
好看吗？有男朋友了吗？结婚了吗？😎
|
 |
169
yulgang 2025 年 8 月 13 日
好看不，好看就多交流，但是不改，不好看就不鸟她。
|
 |
170
lizy0329 2025 年 8 月 26 日
问题一 她是傻逼
问题二 你是傻逼 |
|
171
lizy0329 2025 年 8 月 26 日
有些前端由于需要审核（客户端/小程序），更新等因素不好修改，很多工作是需要由后端来完成的，做到 数据驱动视图
|
Select Language