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