这是一个创建于 33 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在项目协作中和前端有些分歧，整理下情况，想请教大家怎么看。先简单交代下双方背景，避免断章取义：
前端小姐姐：在一家有自己产品的半外包公司做了 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 个角色
但这个项目后期是我这边长期维护，不是短期外包，你更支持哪种做法？
 |
1
luodan 33 天前  12
找定接口的人，比如技术主管，项目经理。按接口定义做，相互不干涉。如果认为接口不合理，找定义接口的人反映，由定接口的人决定，而不是直接找另一方同级的低层沟通。
|
 |
2
yb2313 33 天前 1
猪圈里的猪还以被圈养为豪, 而且又是经典的前端基础功能都不愿意写, 告诉她能干就干, 不能干就滚, 看到这种没脑子还要指挥的人就烦
|
 |
3
Immortal 33 天前 26
这不是又菜又爱叫么...小仙女真是无孔不入
|
 |
5
yankebupt 33 天前
1.谁改都行，交给ＡＩ。考虑到你这边有 unit test 的问题（全部重跑一遍再部署估计一天就没了）交给她改比较合适
2.问问她改要几天工作量，能不能计入工作进度报告，能计入让她改吧。不能计入，问画图的那个人，写死了是为了安全考虑不，是的话，不改。然后以后加的时候，写入自己的工作量（甩锅给画图的） |
 |
6
3231012 33 天前
前后端难道不是平级？互补型打配合，如 1f 老哥说的，按公司的规定走，不清楚的地方直接向直属上级反映或者向公司负责相应板块的请教，避免同级之间争论，往往豪无意义。
|
 |
7
chesha1 32 天前
一确实是她改比较好
二的话，你的方案相当于设计了 8 个更基础的角色？我感觉一个系统有哪些角色最好沿用老的，而不是有某个功能开发的时候又增加更细粒度的角色，除非功能确实有增加需要新角色 一个角色有哪些权限，一个系统有哪些角色，基本上是不会变太多次的，在前端固定写死没什么问题 角色就是一个中间层，没必要拆太细，拆太细那干嘛还要角色呢，直接给用户分配对哪些资源有权限就行了 |
 |
8
xuanbg 32 天前
第一个，肯定要传数组
第二个，没看明白你的设计是怎么回事，正确的做法是使用 RBAC 模型，通过给角色配置资源（页面上的功能、操作）来定义角色权限。根据你们的实际业务情况，你可以根据产品设计的要求预制 4 个角色。以后需要更多的角色或者需要用户自定义角色的权限，做个角色管理功能就行了。 |
 |
9
irisdev 32 天前
1.她的问题，数据结构确定下来不要改
2.权限系统不是前端或者后端就能做的，按照你的设计前端路由表需最好你来维护，现在路由表肯定是在前端吧？两边开发之前没沟通好 |
 |
10
SwaggyMacro 32 天前 9
她是臭鲨臂
|
 |
11
tonytonychopper 32 天前 via iPhone
我是前端，这种还是让前端自己改好，毕竟接口都上线了，改动可能会有兼容问题
|
 |
12
changepll 32 天前
给护就改, 不给护就滚
|
 |
13
dfkjgklfdjg 32 天前
不是你的问题，考虑换前端开发。就背景言论 123 来说这不是一个所谓的“有协作经验的多年老前端”能说出来的话，更像是在 CPU 你 /🐶。
----- 问题 1 ，毫无疑问的前端问题前端处理。 恕我直言“用 XXX 不支持 XXX 类型”作为理由的都是辣鸡。 问题 2 ，不好说，但按照她描述的“传统”，基本上后端做调整是没跑了，多返回一个角色 KEY 去辅助前端做路由表的权鉴。 看起来是因为如果把权限拆到功能级别，组装页面会相对复杂（如果是小程序），她不会处理。所以她的想法是类似于“一个角色固定一个页面功能”的方式。 虽然也不是不能用，但是就没办法满足你对于未来的设计了，这个是需要和 PM 去确认未来对于权限管理的需求设计。 那么在这个基础上，如果不想大吵的话，后端多加一个 [角色管理] 功能，前端按照登录用户的角色 KEY 去做路由是现阶段能解决问题的对策。然后考虑换人接她的盘。 |
 |
14
Geon97 32 天前
不如由 AI 全部接管
|
 |
15
iorilu 32 天前
短期肯定是前端改
后端要不要改以后再说 当然了, 她不改你可以帮她改 |
 |
16
wangtian2020 32 天前 3
鉴定为菜逼前端，后端提供的数据应该足够“原始”以能够处理成任何格式
数组转逗号字符串简单，字符串分成数组时原始内容有逗号怎么办，应该极力避免字符串操作 菜逼前后端检测题：后端传过来的时间格式带不带时区 |
 |
17
sadj0aihnsdo 32 天前
版本 T0 得用屌征服，不能用口，你懂的把？
|
 |
18
mizao 32 天前
主包给的事件不全貌，不予评价！且主观意思居多
|
 |
19
nickytsui1862 32 天前
@wangtian2020 客户端仔表示 第一个问题严重同意，内容传输格式是需要严谨的
至于时间格式带不带时区的问题，个人观点是要标注解释好，起码写文档写个例子（毕竟不同格式有不同的解析方法） 第二个问题，前端要做的是适配 4 个角色，后端多出的角色抛出不就好了，做个兜底。 总的来说 这位前端是真的人菜脾气大 |
 |
20
zqguo 32 天前
我作为前端 leader ，这两个问题，如果是我，我会赞成你的做法。第一个问题：怎么简单怎么来，前端修改这个很快，而且你们接口已经经过完整的单元测试了，除非业务有问题，不然不建议动。第二：很简单的道理，考虑到后期维护，怎么方便怎么来。 但是整个开发流程我感觉缺少了前期的接口评审环节，不知道你们是否做了 ？
|
 |
21
thinkwei2012 32 天前
在我们这儿一般这种问题是谁的能力强谁来改，后端能力强后端来改，前端能力强前端来改。
当然，项目进度不赶的话，就找上级来定夺一下 |
 |
22
theprimone 32 天前
问题一就给我看傻了
|
 |
23
JoJoWuBeHumble 32 天前
list 数据不要，要字符串自己分割，这是人能提的出来需求啊。
你要是外部图表框架，要求按框架规定的数据结构返回数据我都能理解。 怕不是她是把上家公司的轮子带过来，自己不会改，才叫你改的 |
 |
25
zihaoin1551 32 天前
产品经理最大，前端服务于产品，后端服务于前端 —— 这句话不知道怎么得出来的。
前后端不是两条并行的腿吗，哪儿存在前后脚一说？ |
 |
26
picone 32 天前
问题一：如果你以后换了个包后端是不是也得跟着重构呀
|
 |
27
interim 32 天前
问题一把我看傻了 +1
|
 |
28
MyFaith 32 天前
什么臭傻逼
|
 |
29
1024potato 32 天前
问题一： 肯定要返回数组，数组类型更方便对数据进行二次处理（增删改查）。
问题二： 你们两不存在对错，你的重点是扩展性，她的重点是简单，可以平衡下。 你把需要的角色和权限数据在数据库配置好，然后自己调接口把返回的数据以文件给前端，这样前端没增加工作量，你又保证了扩展性。如果后期需要改动权限这块你再找前端沟通改成接口获取 |
 |
30
lx0758 32 天前
上一个后端把她舔舒服了
|
 |
31
salmon5 32 天前
说到前端，我不看内容，直接下定论：前端菜逼多，而且还不知道自己是菜逼
|
 |
32
jjx 32 天前
我的原则是遵循原先的数据结构设计
比方说后端数据结构是数组,就是数组,是字符串就是字符串 除非前端太菜, 否则后端不做这种越俎代庖 事情 |
 |
33
xuwuruoshui 32 天前
太菜了
|
 |
34
robinchina 32 天前
我只全干·······支持改前端··能用数组用毛字符串啊········角色权限写死后面工作多得很····
|
 |
35
AccelerXu 32 天前 1
这波我站老哥.....这前端明显是被惯出来的.上一个后端对她太好了
|
 |
36
DonaldY 32 天前
这种问题，一般都是能力强向下兼容，为了 deadline 和 少争吵，多做一些。
|
 |
37
EJW 32 天前
干它就完了😡
|
 |
38
szdubinbin 32 天前
我算是知道为什么有些老接口是以一种莫名其妙格式返回的原因了
 ，如果向上反馈和同级沟通不了你就躺平吧，当然为了后面的客户端还有其他正常前端觉得 “后端定的什么**接口”，我建议你加个参数如果传了返回数组 |
 |
39
jpyl0423 32 天前
什么菜鸡前端，不管从什么方面来讲肯定传数组啊
|
 |
40
way2create 32 天前
“后端服务于前端，所以前端比后端大，后端应该多听前端，让改东西要配合” 如果这是原话那属实看笑了
|
 |
41
tabc2tgacd 32 天前
感觉这前端不专业，明显是她自己的问题。
|
 |
42
337136897 32 天前
想个办法和前端小姐姐打一炮？ 要让她对你服气
|
 |
43
sampeng 32 天前 via iPhone
你们 leader 呢？ leader 这个时候装死？
|
 |
44
Zenon 32 天前
就不改，跟我上级说去吧
|
 |
45
jeasonzuo 32 天前
1. 前端改比较合理，已经部署好的项目再修改字段格式不能保证兼容性
2. 找技术主管，如果业务保证角色权限以后不会变（大概率是不可能的）那就不用做动态权限配置，既然是你长期维护，考虑业务需求，应该很好说服主管 |
 |
46
peng7534211 32 天前
开技术评审，把接口文档写清楚，提前有疑问提出，过期按文档走，除非领导出面
|
|
47
peng7534211 32 天前 1
还要考虑这个领导跟前端小姐姐的关系，没关系，该怎么就怎么办
|
|
48
irisdev 32 天前 22
一个技术+日常贴，四十条回复有四条硬往性上带，可见 v 站至少有 1/10 的煞笔
|
 |
49
yurenfeijing 32 天前
我是前端，问题一毫无疑问肯定是前端改
1. 你说这是一个变更请求，所以接口格式肯定提前跟她定好的 2. 前端工作量不大，只要获取和保存的时候处理下就行了，热更新发布上线也更快，对客户造成的影响更小 3. 后端可能涉及到落库问题，改格式可能要刷库 4. 外包公司什么水平懂得都懂（就我接触过的几个而言） 问题二看场景，SAAS 这种肯定是你这个动态权限配置，普通的小程序可能都没几个人用，怎么做都行，看产品经理怎么说 |
 |
50
journalistFromHK 32 天前 2
你小子是不是故意黑我们前端的😡
|
 |
51
julio867 32 天前
那个“前端言论”没有一条合理的，尤其是第 2 条，但凡在一个稍微正规的团队待过，都不会说出这种没有“见识”的话~
至于前后端争论的“接口”问题，其实不应该是具体岗位的人在扯皮~ 就如很多评论说的，“接口契约”在开始前就应该由项目负责人开评审会确定下来，任何人都可以在会上提出自己的想法，最后由负责人拍板~ |
 |
52
visper 32 天前
第二个按你的。第一个大多数时候也按你的，除了一种很特别的情况：假如前端用了一套写得很差的封装比较死的前端组件，它一定是要值是豆号分开的。而她要改起来别人封装的组件很麻烦。那后端改一下也不是不可以。
|
 |
53
zhwithsweet 32 天前
长的漂亮吗？
|
 |
54
THESDZ 32 天前 2
针对双方语言逐条回复:
你没有正经上过班没有和他人协作过都是自己闭门造车，我是多年老前端有协作经验，多听听我的意见 > 没有任何因果关系，爹味发言 产品经理最大，前端服务于产品，后端服务于前端，所以前端比后端大，后端应该多听前端，让改东西要配合。 > 前端和后端均服务于产品，没有所谓后端服务于前端这种说法，强行因果关系 你的数据结构和一些机制和我们公司不一样，这让我很不习惯，开发得很难受。 > 数据结构就是数据结构，机制如果是标准形式，只看公司对于这些如何选型，跟“个人”习惯不习惯没有因果关系，按照这个说法，那我每个月没有拿 100w 的美刀，很难受，所以老板需要让着我？ 接口字段类型调整 > 数据结构是对现实拙劣地模仿，现实世界明显数组，非要写 string 。菜 角色权限设计 > 具体的实现不该影响暴露的接口，这个地方不该暴露复杂度给外部，动态如果做了初始化其实就是静态，没必要争论对错，直接暴露出去的接口，给前端感知为静态即可（通过配置文件或者 sql 初始化）。多余地炫技。 前端“小姐姐” > 性别在这其中没有任何的影响因素，不该提供这个信息。有“炒作”嫌疑 以上只说出个人基于当前信息的下的判断。 |
 |
55
cocong 32 天前
开发前没有讨论好吗？这些细枝末节的东西其实不是什么问题，开发前没沟通好才是最大的问题。
|
 |
56
SyncWorld 32 天前
我都不反驳，你让怎么改，怎么改，我不给自己添堵
|
 |
57
Chyen 32 天前
这么简单的东西前端自己转数组不就好了，我以前后端给我一堆 json ，我自己转成二维数组对象，转的的我真恶心。
不过现在都有 ai 了，元数据丢给 ai 让它给你生成转成你要格式的数据不是 ez 吗？ 真羡慕现在工作的人，省去大量工作时间 |
 |
58
ardour 32 天前
都不用看题主的背景交代，只看两个问题都把我看笑了。 典型的又懒又菜 🤣
|
 |
59
7inFen 32 天前
这是小仙女纯纯傻比
|
 |
61
dudubaba 32 天前 1
所以有低级程序员和高级程序员之分，前端特别明显，都是转行的压根都不懂数据结构，只会傻瓜式拼接，一个 vue 至少提供了 70% 的前端岗位
|
 |
62
lscexpress 32 天前 2
道理站你这边，但是我们站你这边没用。你想想怎么把工作快速做完，好早点下班吧。因为这个职场环境你多呆一会儿，寿命就要成倍减少，除非你血压低。
|
 |
63
Yjhenan 32 天前
还有专门要字符串的啊，我看见字符串就头大，数组这种原始数据多好用
|
 |
64
wukaige 32 天前
就不改
|
 |
65
sentinelK 32 天前
这些不应该由你们来交流定义。
产品和架构是干什么的？ 在信息不完全透明（需求，架构设计，扩展性考虑等）的情况下，讨论 API 的合理性与修改属于空中楼阁。 |
 |
66
m1ng 32 天前
把你们的分歧交给 AI ，让 AI 判断
|
|
67
sentinelK 32 天前
如果我司有这种情况：
假如我是后端，我会让前端直接发 sql 。 反之假如我是前端，我会让后端传本地渲染富文本。 所以讨论这个没意义。 |
 |
68
GThui 32 天前
说实话，从软件层面，考虑维护性，站你这边。同级沟通不了不要沟通，找上级沟通确定，因为她听不懂。
|
 |
69
kenshinhu 32 天前
这种情况我会要求把前端的 API 接口请求来看一下给他修改的代码吧，这里可以把前端的修改权限也入侵一下。
以便了解一下前端的网络之后的接口再作适应。 其实嘛～大家的目标都是一致的，获取方向不同 这种自己消化就可，早点消化完早点下班。 你也不想项目有问题出现时，都找所有技术来一遍排查处理吧 |
 |
70
xiangyuecn 32 天前
产品经理 其实 跟开发部门基本可以说是毫无干系的😂
爱管开发的产品经理一般是爱瞎指挥的傻屌😁 |
 |
71
Sentimental 32 天前
正常开发流程来说，不应该双方先沟通好吗？各干各的，都按自己的想法来，最后对接的时候肯定是有出入的，双方都不愿意妥协，矛盾就产生了。
你改变不了别人，作为上游，你可以主动跟前端提前沟通好，达成一致是主要目标，至于技术层面的考量，跟有些人说了也白说，讲不清，省点时间，早点把活做了，该干啥干啥 |
 |
72
test00001 32 天前
说句不爱听的，看完你俩这背景，属于是卧龙遇见凤雏了。如果你们公司没有技术总监，全靠你俩商量的话。那还是早点开溜吧。
|
 |
73
jackding1208 32 天前
不提性别这前端就是个彩笔
|
 |
74
rxswift 32 天前
beyound 的前端小姐姐
|
 |
75
pikes2023 32 天前
服务端开发的时候，会和前端商量返回的字段结构吧，尤其第一次合作。前端明显改造一下就好了，可能是她不想改
|
 |
76
esee 32 天前
既然是公司团队多人协作，那应该有 leader ，功能设计接口定义怎么写肯定有规范，按照规范来就行了呗，比如你说的这个数据结构转换的问题，既然前期已经协商好了就没必要跟她吵啊，非要改那去提工单，只要给我算入工作量怎么都好说，一句话就想让我改那绝无可能。反正在我看来，双方都有问题，我遇到这种情况左耳朵进右耳朵出，随别人怎么说，只要需求提工单，再蠢的功能我绝不多说两句。最后，自己做东西做久了，会有一些习惯或者说强迫症，没必要纠结这些东西
|
 |
77
kakki 32 天前
问题一
她是傻逼 问题二 Role 通过约定命名定义,即可以是固定的也可以是动态的,毫无影响. |
 |
78
digimoon 32 天前
你们不是先定好接口，然后前后端都按着接口文档开发的吗
|
 |
79
31415926535x 32 天前
加个 bff 层的事（
|
 |
80
oom 32 天前 1
if 颜值不错 {
改 } else { 滚 } |
 |
81
woniu7 32 天前 4
波伏娃说了，让你改接口
|
 |
82
auhah 32 天前
问题一 她是傻逼
问题二 她是傻逼 总结 她是傻逼 |
 |
83
dabennn 32 天前
先做方案设计和评审，这些问题都是在方案评审中讨论的。问题一前端做没有什么太大问题，问题二看产品已有设计和发展方向，要讨论也是和产品去讨论，功能层面沟通好再掰扯设计的事
|
 |
84
williamx 32 天前 1
首先说结论：前端没有错。
第一个问题，谁能力强谁改。前端不会，你非要叫她改，莫非你也不会？你加个接口调用原来的接口函数，把结果转换一下再给前端，并不费事，也不影响你所谓的测试。 第二个问题，前端按照 UI 设计没有错，避免了过度设计。你后端追求灵活和可维护是你的事情，你给她的接口按固定角色方式就行了。你把灵活性丢给了前端，你考虑了她的能力没有？不是为了自己剩麻烦而给她找麻烦吗？我们后端的复杂和灵活的设计一定是要在接口层吞掉的，给到前端一定是简单好用的。 |
 |
85
googleaccount 32 天前
好怕 她直接给你来女拳那一套
|
 |
86
wgbx 32 天前
发现大家无条件站队第一条，假设是这种情况，后端接口一下子 string 数组一下子 string 字符串，那这个事情就是后端没理了，前端组件已经高度复用，为什么非要针对这种情况为后端转数据结构呢？
很多事情站各自角度都说说法，这种事情发帖正常，吵翻天就没必要了，前后端都是顺手的事情，工作中戾气太大天天骂这个骂那个也是没必要的 |
 |
87
EriczzZ 32 天前
joinString 干嘛的 这点破事还用改接口？
|
 |
88
BeforeTooLate 32 天前
碰到这种情况，应该向你的上级确认下，具体的标准到底是怎么样的，以后都按那套标准来就行了。完全不用 battle 了，没意义，因为完全说服不了前端就别浪费力气了
|
 |
89
softlight 32 天前
这不手把手教的机会来了么
|
 |
90
Asuka0947 32 天前
我的话看给多少人天。（总人天-实际开发人天）/ 总人天 > 30% 勉强能干，>40%小爽，>50%必须能改啊。有的修改给到我这里，已经>200%了，必须大力狠狠地改 TM 的。
|
 |
91
McVander 32 天前
问题 1：从长远性考虑，数组结构（原始结构）就是最适合的<前端问题>
问题 2：前、后端的方案都可以用，但是后端的方案普适性更强。这个看业务短期业务其实都可以 |
 |
92
92Developer 32 天前
什么小姐姐，要么小姐，要么姐，哪那么多新奇的称谓，惯的毛病。
|
 |
93
IamUNICODE 32 天前
第一个前端改
第二个，贵司在做项目前不开会统筹设计前后端的吗？这什么脑残团队，震惊 |
 |
94
stanley0black 32 天前
我是前端，你说的对。
不会或者不了解后端开发模式的前端就是切图仔，没有发言权。 |
 |
96
0x663 32 天前
你俩谁是外包？谁是外包谁去改
|
 |
98
NjcyNzMzNDQ3 32 天前
`前端言论` 一副高高在上没有一点尊重人的意思，就是惯的，就这沟通态度，无语
|
 |
99
hafuhafu 32 天前
这种一定要后端接口返回符合组件要的数据格式的真的是神人...这甚至不是偷懒的问题。
|
 |
100
edisonwong 32 天前
1. join 的话里面有逗号咋整
2. 脑子有坑啊，我要是前端巴不得权限控制全交给后端，后续新增角色就不用改前端了 技术菜 + 高高在上 = sb |
Select Language