前两天冬至(这边流行冬至前两日就开始吃一种像饺子的东西,误以为那就是冬至),很多亲戚聚在一起吃饭。我拿着一本《xx多线程编程》在啃,八大姨的小姑子在教育上小学的儿子要好好学习。
- 「儿啊,你看X叔叔多认真,30多了还这么努力,你要向他学习」
- 「妈妈,爸爸和叔叔一样的年纪,叔叔好厉害!能看懂那么厚、那么多英文的书,爸爸一点都不懂!」
- 我摸着小孩的头笑着说:「你爸才厉害,整天开车出去耍。你要好好学习,小时不努力,长大像我一样30多岁还要看书」
- 然后,他妈来了一句「儿啊,你要努力,要是30多岁还像叔叔一样学习,我和你爸就要喝西北风了」
瞬间头顶飘出 -20000!的雷击伤害,双倍暴击并产生10秒麻痹效果,原来他妈夸我努力就是为了这句!
注:本人没爆粗口,他妈的后面没有”的“字。
事件背景:
年轻时因为英语问题,从名牌大学毕业变成一个大龄高中毕业生,学的又是冷门物理专业,除了读书一无是处,年近30开始做程序猿总算发挥一点点特长。
真是应了少壮不努力,老大做程序猿这句话。公司派发稀奇古怪的任务,我也不断的调整方向,DELPHI、C#、单片机C语言、Android、Java都经历了一遍。
每天除了上班就是学习。逐渐发现这公司真地不利于走技术路线,例如:
1,经常成立XX小组推进信息化建设,然后列出一群组员,除我之外其他都是各部门经理,一群“软件设计师”指导一个程序猿的画面不要太美。
业务设计上如果讲道理赢了”设计师“们,以后没好果子吃。如果按照他们要求来,要增加很多工作量和不必要的冗余。
若是界面的个性风格也忍了,但是某些”设计师“也跟我学过一点数据库设计,对数据库设计指手画脚,一会说联合主键好,一会说未审核的订单和已审核的名单要分两张表设计。
内部培训软件开发,本意是让其他人了解下企业信息系统,哪些可以做,哪些不可以做。结果我还真是搬起石头砸自己的脚。
2,老旧OA用Lotus数据库太落伍,公司换个新的几十万又嫌贵,我跳出来说自主开发给十分之一就好。用接近一年反复重构,搭建好开发平台,顺便带几个人做好了OA。
3,最大的一次委屈来自于转型java
A领导听OA厂商说java好google,淘宝们都用java,.net快被淘汰了,运行windows系统又浪费服务器资源(言下之意是IBM服务器几百万,运行windows是在烧钱)。A领导大手一挥转java,于是我开始转Java。
逐步用Java来搭建开发平台,持续做了几个月,也做了一个业务模块上去运行,遇到JS问题一时没搞定(全栈==全废,JS都是复制粘贴的)。可能领导很不爽,没过收到A领导招聘java高手的邮件。
心里一万匹草泥马奔过,面试java高级程序猿竟然不是唯一懂java得我而是只懂点sql的A领导来做(后来换个角度也想明白了,从A领导角度看,虽然我技术是比他好那么一点,但公司业务他熟,做管理多年他看人的能力也很强)。
经过最高总经理批准,高手来之后工资是我的两三倍,废弃了我开发一半的平台重头开发。很快调整心态,我默默地想:反正高手不来我也没有工资加,来了跟着学点东西也好,不用自己辛苦踩一遍Java的坑,用高手的架构也是题中之义。
但每次请教,高手都是让我调试代码,耐心看看debug信息。开始以为只是他不愿意教我,后来他很多功能都问我原来平台上有没有,有就移植到新的平台(底层都是SSH或srping+springMVC+hibernate)。
到这里我明白了,原来”高手“是靠忽悠出来,再后来他问我什么我也说不知道。下决心自己做一个完善的开发平台出来,然后再给高层演示的时候我拿一个更好的方案出来,不料默默准备了很久的大招没有打中人。
因为,半年后”高手“拿着20来万工资离开了,A领导又找到我,说那个系统已经做完大部分,要继续发挥它的价值,你来维护吧?顿时心里被一群草泥马来来回回的跑过,把我接近完成的系统展示给他看。
整个权限设计,在jsp页面充满了下面这种代码。不说jsp里写Java代码的古典风格,不说代码都用角色了还要权限来干什么?也不说使用名称判断而不使用id这种低级错误。
这种”高深“的问题给A领导解释是自找麻烦,我着重演示了系统的不安全性(简历上是担任项目经理,参与多家银行系统的建设,对于安全性方面很有研究)。
不安全性:一个外网IP访问的系统,掩耳盗铃控制html的内容,不登录系统,浏览器输入菜单1的地址,各种数据随便访问。
1
2
3
4
5
6
7
8
|
if (角色== "经理" ) { 显示菜单1(); } if (角色== "员工" ) { 禁止菜单1(); } |
终于说服A领导,那个系统没有必要使用了。当时我也注意到,”继续发挥它的价值“这句话的深层含义,A领导也明白花冤枉钱招人了,但放弃系统等于打自己的脸,往上报告高层也不好交代(公司规定每个高级人才辞职都要问责上司的)。
我不想背这个锅,顺着A领导去做讨得欢心也不给我加一分钱,还要为系统问题买单。然后,A领导和我的话更少了,推广使用我的开发平台,有任务丢给新人,然后新人不会的我来搞定。之前招聘高手来做Java平台许诺的十万奖金也没人再提。
如果选择表面维护遗留系统(实际用自己的平台),十万奖金是可以向高层申请到,但考虑到一群”设计师“出力的情况,有一万到手就不错了。即使一万对于他们只是零钱,对于我是巨款,但有些事我做不到妥协。
发奋
马云说过,辞职只有两个理由。要么是钱给得不够,要么是心受委屈了。两个理由都有了,是时候该换个工作了。
不懂忽悠也不想学忽悠,只好修内功。上班有空就看技术书籍,下班也看,走亲戚也带着书,于是有了上面的事情:
—————————————-
看完评论发现权限设计是一个经典的老生常谈问题。会的人胸有成竹、对权限问题不削一顾,不会的人还在苦苦思索,到处找代码。
初入门我先后用了吉日嘎啦、伍华聪、金色海洋等人的权限设计,那时他们争论很激烈,下篇把我的设计和代码发出来,让不会的人少走弯路。
设计基础:用户、角色、权限三大核心表,加上用户角色、角色权限两个映射表(用于给用户表联系上权限表)。这样就可以通过登录的用户来获取权限列表,或判断是否拥有某个权限。
物理学总喜欢不断抽象,试图建成大统一系统,比如牛顿力学是相对论在低速状态下的一个特例。软件思想也是如此,
任何权限的需求,都是为广义的用户分配角色,角色拥有广义的权限。角色是最重要的中枢,隐藏做幕后黑手,从不出现在业务代码里,用行话说就是解除了用户和权限的直接耦合。
角色把用户抽象化了,几百个用户变成成几个角色,用户->角色->权限写成通用判断权限的方法:currUser.IsHave(xx权限)。核心就是一个sql联表查询语句,查询条件为用户id。
例如:
- 部门权限:部门也是一种用户,建立 部门表、部门角色表。通用权限方法里加上 当前部门->部门所属角色->权限
- 职位权限:职位也是一种用户,建立职位表、职位角色表,同上
- 菜单:也是一种权限,建立 菜单表、角色菜单表,就把菜单纳入了权限管理。通用权限方法里加上 角色列表->权限、菜单