吐个槽，顺便问问 v2 的兄弟

前排占座

我觉得没啥问题，可能我也是外包思维&软件外包也是外包

没什么问题呀~~可能他的回答方式不太好

有什么问题么？总经理和员工能看到的菜单肯定不一样啊，不从数据库获取 难道前端写死？

这不是正常的权限组需求吗？别抵抗了

就算自己公司的项目,部门不一样看到的菜单也不一样啊

你说的对！！

...权限和模块不都是这么做的么，，配置都是写到数据库里的。RBAC 了解下。

@kamal
@Mogugugugu
@bobbychen
@moresteam


你们说的有道理，但是我觉得，应该的实现思路是把这个东西写到 页面模板 里面 。权限控制不同的人看到不同的内容，权限越高看到的越多。如果说需要改 汉字 英文 的话，那就是 i18n 放到 properties 文件。也用不上放在数据库。。。

当然也可能是我太年轻了（坦诚将，才干了 1 年多

@lllllliu 我们目前正在参考 rbac 做，但是由于上司的这个要求，我把 动态菜单和权限部分揉起来了。 发帖只是说了 动态菜单这部分。

可配置意味着代码写好就不用管了，而且菜单改个文案图标什么的改数据就行，不用改代码，而且改了就生效。

楼主还是项目经验少了点，没想过以后别的项目可以复用这个权限框架。

这不是正常的权限组需求吗？别抵抗了

@zhaogaz 你说的写在页面模板里面也是一种配置不是？多思考少抱怨

难道写死?

段位不够啊 兄弟 菜单内容动态很正常啊，考虑了后面需求变化的可能没啥毛病

@xuanbg 是的，我确实是项目经验少。

所以我能问问么？诚心求教。

我这边有一部分复用，我们的复用方式是，把上一个项目的代码拷贝过来，删删改改，上一个项目相关的内容删掉，留下比较通用的，如登录啊，用户啊，这些。

你说的复用权限框架是这样么？如果不是的话，你说的复用权限框架怎么做呢？能说说习惯做法么？

@zhaogaz 举个例子，页面模板里面写死了，增加一个菜单项怎么处理？减少一个怎么处理？菜单对应的权限有变动了？都改模板？你是怕前端的 KPI 完成不了，工资拿的不踏实？
那如果想要允许自定义菜单显示顺序呢？

可配置还有一个好处，就是用户端得到的菜单可以按授权显示，前端拿到什么数据就显示什么菜单。这样前端就不需要根据用户权限来判断哪些显示哪些隐藏了。总之系统会复杂点，但好处也是很多的。

我们是连路由都是配置出来的。做第一个项目的时候大家也有疑虑，但从第二个项目开始，开发进度远超原先的模式。大家只需要关注业务逻辑，再也不用管用户、权限这些底层的东西了。我们也算是互联网行业的，从我进公司以来，已经做了十几个项目了，全部是公司自己用的各种业务管理系统。

@zhaogaz 我们更进一步，封装了一个框架，新项目直接使用这个框架就行。当然你复制目过来删掉无关代码也是一样的效果。

这不是很正常吗？比如说你现在用的很多大厂 app，页面的排版配置都不用经过开发了。。直接有权限的 PM 和运营就可以配置。

背后应该是简答 /负责算法吧，简单来说不同的人进来页面看到不同的功能菜单和对应的 Icon。所以先要获取登录用户的 ID 来对应权限，进而展示该权限下的菜单配置。大概这个意思吧。

项目刚上的时候第一件事情就是把后台权限系统这么搭建好，为得就是让运营以后别来烦我，自己配，所以放弃抵抗吧

@zhaogaz 你说的模板是文件，领导要是的数据库表，本质没区别，你是嫌要多写几个页面吧？

看到只是你们在权限的意见不统一，为未看出谁对错，可能我还停留在 XXXXX （崩溃中.... o(口)o

以前我们多个项目也是按你这位上司的思维做的，唯一不同的地方，你们把它叫做权限控制的一部分，我们是把它从权限中剥离做成一个独立的配置子系统。

还是太年轻啊

菜单文字，icon 都是可配置的，而且是动态权限，甚至还维护了一个权限路由表

对内的报表，对外的活动配置，这玩意要用前端去配模板，那效率，是不是配完了还得 review 一次代码，各种测试回归一次？

有必要说上司是傻逼吗？

差不多，我司框架页面有啥按钮基本是写数据库的，web 开发界面上增加删除按钮，按钮事件也是写数据库的，页面样式也是写数据库的。写查询 sql 可以控制按钮的显示隐藏，也可以配置权限控制

楼主还需要在酝酿酝酿

你不足的不是见识少经验少，这种都是小问题，刚工作肯定都这样。
你问题是自己觉得不对就觉得是别人的错，别人傻逼，你那点经验和人家比起来，外人按概率想想也知道谁的解决方案更可靠，何况人家是你领导，你再干两年是不是什么架构师 CTO 都不放在眼里了？和自己意见不一样的都是傻逼？
你的想法和解决问题的思路都是基于你的知识和经验，然而自己多少斤两说实话自己不清楚么？
三人行必有我师，何况是职场前辈，太把自己当回事的人很大概率走不远。。。

@newtype0092 您说的非常对，我也很赞同。

不过另一方面我没把自己太当回事。坦诚讲，说上司傻逼并不恰当，准确描述应该是 不求上进的普通人。

刚进公司的时候我菜的跟鸡一样，上司基本也没帮什么，他主要做了 2 件事。一是告诉你干什么业务，二是告诉我们以前哪个项目有类似代码。问他点东西，他搜搜搜国内的 csdn 给我扔过来一篇，我这边有空的时候看的官方资料才知道是怎么回事，然后告诉他这博客哪里写错了。

半年多的时间，我自己做笔记，做总结，他们日复一日的做业务。结果是显而易见的。我平时甚至可以唬住上司做点东西。

权限和动态菜单这部分我以前确实没做过，再加上我认为他很少做思考，只是把以前的经验用上一遍又一遍。

经过我上面的描述，你应该理解我是什么心态了吧。很多时候就事论事，其他的背景渲染我都没有写。

当然我也非常感谢您的好心提醒。

看上面大家的回复，但我怎么觉得 “菜单加一个，减一个，对应的就是功能的变化了” 这句话没有什么错啊！

你让我对自己产生了怀疑，虽然没在外包公司做过，但我有个外包的思维[手动滑稽]

@zhaogaz 一是告诉你干什么业务，二是告诉我们以前哪个项目有类似代码，搜搜搜国内的 csdn 给我扔过来一篇
没毛病啊，就是这样做的。
每个人都要手把手教，那不累死。还要进一步告诉你为什么这么做，为什么你那么做不行，和你做各种思想工作才能安排好工作，还得防着你不按公司的来做，哎，真的要累死。

如果业务很多的话，入库是比较优雅的方式了。

我做业务很简单，你想要多优雅都成，只要给时间就行了，工作安排好了就行。

@xsir2020 看你回复的内容，应该就是针对我 30#写的内容吧。

这么跟你说吧，转行之前，我做了几个月媒体。对于网络信息的真伪辨别是有一定考虑的。信息在传播的过程中容易出现偏差，更何况很多人在 csdn 之间抄来抄去。我个人养成的习惯是尽可能的找谁第一个说了这事，发布了文档。这种资料的质量要明显高于二三四手的东西。

我上司这个人英语不太行，他极少极少看 manual 或者是 reference。他自己的理解基本靠 csdn 这些。他找着做一遍，成了就不管了。为什么这么做？出现不同的变化怎么改？他都不知道。

我举个例子，昨天我们讨论了后端，如果部署多台服务器的话，session 共享怎么解决。

他说：用 ngnix 配置一下就行了。
我问：不用改项目中的内容么？，
他说：不用。
我问：那这个是什么原理呢？（我以前没做过，但是我猜了一下，真正的 session 共享肯定需要交互多个 server 的内容，如果项目中没有改东西，那么说明他说的 ngnix 配置只是把固定的请求转发到固定的 server 上，根本没有共享）
他：随便搜一下就有（然后敲键盘开始搜）
。。。。
剩下的我就不说了，结果就是他承认 ngnix 那个配置不是共享 session

你还有一个理解问题是，我压根没想说对方怎么怎么教，不知道你怎么理解出的这层意思。我本身材料专业，一路自学到这个份上，没必要手把手。

我希望的是：上司能凭借自己的经验，自己对代码的理解思考，给我做一些指点。而不是随便找个 csdn 东西扔给我。那我问上司问题有任何意义么？

我周围人包括上司，他们的行为特点是，会做 xxx，但是框架模型为什么这么做，为什么这么命名，对象有什么功能能力，有什么由历史原因沿袭下来的做法，没有思考。

还有不少，想了想我就不打字说出来了。

当然以上原因有可能是因为我所在环境太差了。哎

正常的，千人千面，遇到过非常 nice 的同事和上司，也遇到傻逼同事和上司，见怪不怪。我做 app 的，有时候不能理解产品的需求为啥要这么错，问产品他说老板让做的没啥本法。那就只能做了，麻烦是麻烦了点，后面维护就方便多了。

@zhaogaz 我想说毕竟是工作，一些需求下来领导能给你个大致的方向就不错了，不必去究根问底我觉得。毕竟工作是工作不像学习，可以有一种很浓重的学习讨论氛围。让我想起了那个段子，你一个砍柴的和一个放羊的讨论了一天的人生，他的羊是吃饱了但是你的柴呢？ 既然觉得上司不行，周围环境不行，那就厚积薄发跳出去换个环境行的。

这样做是可以的，主要是要考虑数据缓存。