最近在项目协作中和前端有些分歧,整理下情况,想请教大家怎么看。先简单交代下双方背景,避免断章取义:
前端小姐姐:在一家有自己产品的半外包公司做了 5 年,主要做网页( Vue ),也偶尔协助小程序开发。
我(后端):7 年自由野生全栈,一直是前后端独立项目开发,后端主力是 Ruby on Rails ,也写过 Node.js 、Vue 、小程序、爬虫、量化、脚本、Docker 、Android 插件、chrome 扩展程序等,属于遇到需求就学、全链路自己处理的那种。
前端言论:
1.你没有正经上过班没有和他人协作过都是自己闭门造车,我是多年老前端有协作经验,多听听我的意见
2.产品经理最大,前端服务于产品,后端服务于前端,所以前端比后端大,后端应该多听前端,让改东西要配合。
3.你的数据结构和一些机制和我们公司不一样,这让我很不习惯,开发得很难受。
问题一:接口字段类型调整
后端某接口已开发完毕,并通过自动化测试,现已部署上线。 前端提出一个变更请求:希望将接口返回字段从 ["a", "b"] 改为 "a,b"( Array → String ),理由是她使用的 Vue 组件只支持 string 。
我当时建议:在提交接口前 split(',')一下 即可转换为数组,不必改接口结构。她坚持要后端改接口格式,当时项目是有点赶的。
考虑到接口已经稳定并经过测试,这样的调整需要把相关的 n 个测试用例都变更重新测试和部署。请问在这种情况下,是否应该满足这样的修改请求?
问题二:角色权限设计
期间开发一款小程序,用户分为 4 类角色。我的后端做法是: 将权限拆成 8 个基础点(页面、功能级别),后台可自由配置角色权限,未来如需新增角色,配置即可,无需修改代码。
前端做法是:根据 UI 图写死了 4 个角色及对应权限。认为后端接口不应该做成动态权限配置,理由是她们公司都是按固定角色方式来做。
前端指出后端没按 UI 设计图的来,并建议后端也应该写死为 4 个角色
但这个项目后期是我这边长期维护,不是短期外包,你更支持哪种做法?
后端要不要改以后再说
当然了, 她不改你可以帮她改
-----
问题 1 ,毫无疑问的前端问题前端处理。
恕我直言“用 XXX 不支持 XXX 类型”作为理由的都是辣鸡。
问题 2 ,不好说,但按照她描述的“传统”,基本上后端做调整是没跑了,多返回一个角色 KEY 去辅助前端做路由表的权鉴。
看起来是因为如果把权限拆到功能级别,组装页面会相对复杂(如果是小程序),她不会处理。所以她的想法是类似于“一个角色固定一个页面功能”的方式。
虽然也不是不能用,但是就没办法满足你对于未来的设计了,这个是需要和 PM 去确认未来对于权限管理的需求设计。
那么在这个基础上,如果不想大吵的话,后端多加一个 [角色管理] 功能,前端按照登录用户的角色 KEY 去做路由是现阶段能解决问题的对策。然后考虑换人接她的盘。
2.权限系统不是前端或者后端就能做的,按照你的设计前端路由表需最好你来维护,现在路由表肯定是在前端吧?两边开发之前没沟通好
第二个,没看明白你的设计是怎么回事,正确的做法是使用 RBAC 模型,通过给角色配置资源(页面上的功能、操作)来定义角色权限。根据你们的实际业务情况,你可以根据产品设计的要求预制 4 个角色。以后需要更多的角色或者需要用户自定义角色的权限,做个角色管理功能就行了。
二的话,你的方案相当于设计了 8 个更基础的角色?我感觉一个系统有哪些角色最好沿用老的,而不是有某个功能开发的时候又增加更细粒度的角色,除非功能确实有增加需要新角色
一个角色有哪些权限,一个系统有哪些角色,基本上是不会变太多次的,在前端固定写死没什么问题。角色就是一个中间层,没必要拆太细,拆太细那干嘛还要角色呢,直接给用户分配对哪些资源有权限就行了。
2.问问她改要几天工作量,能不能计入工作进度报告,能计入让她改吧。不能计入,问画图的那个人,写死了是为了安全考虑不,是的话,不改。然后以后加的时候,写入自己的工作量(甩锅给画图的)