”儿啊，你要努力，要是30多岁还像叔叔一样学习，我和你爸就要喝西北风了“

前两天冬至(这边流行冬至前两日就开始吃一种像饺子的东西，误以为那就是冬至)，很多亲戚聚在一起吃饭。我拿着一本《xx多线程编程》在啃，八大姨的小姑子在教育上小学的儿子要好好学习。

”儿啊，你看X叔叔多认真，30多了还这么努力，你要向他学习“

”妈妈，爸爸和叔叔一样的年纪，叔叔好厉害！能看懂那么厚、那么多英文的书，爸爸一点都不懂！“

我摸着小孩的头笑着说：”你爸才厉害，整天开车出去耍。你要好好学习，小时不努力，长大像我一样30多岁还要看书“

然后，他妈来了一句”儿啊，你要努力，要是30多岁还像叔叔一样学习，我和你爸就要喝西北风了“

我瞬间破防了，原来他妈夸我努力就是为了这句！

 

 

 

 

事件背景：

 

年轻时因为英语问题，从名牌大学毕业变成一个大龄高中毕业生，学的又是冷门物理专业，除了读书一无是处，年近30开始做程序猿总算发挥一点点特长。

 

真是应了少壮不努力，老大做程序猿这句话。公司派发稀奇古怪的任务，我也不断的调整方向，DELPHI，c#，单片机c语言，android，java都经历了一遍。

 

每天除了上班就是学习。逐渐发现这公司真地不利于走技术路线，例如：

 

1，经常成立XX小组推进信息化建设，然后列出一群组员，除我之外其他都是各部门经理，一群“软件设计师”指导一个程序猿的画面不要太美。

 

业务设计上如果讲道理赢了”设计师“们，以后没好果子吃。如果按照他们要求来，要增加很多工作量和不必要的冗余。

 

若是界面的个性风格也忍了，但是某些”设计师“也跟我学过一点数据库设计，对数据库设计指手画脚，一会说联合主键好，一会说未审核的订单和已审核的名单要分两张表设计。

 

内部培训软件开发，本意是让其他人了解下企业信息系统，哪些可以做，哪些不可以做。结果我还真是搬起石头砸自己的脚。

 

2，老旧OA用louts数据库太落伍，公司换个新的几十万又嫌贵，我跳出来说自主开发给十分之一就好。用接近一年反复重构，搭建好开发平台，顺便带几个人做好了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的地址，各种数据随便访问。

 

if(角色=="经理")
{
   显示菜单1();
}
if(角色=="员工")
{
  禁止菜单1();
}

 

终于说服A领导，那个系统没有必要使用了。当时我也注意到，”继续发挥它的价值“这句话的深层含义，A领导也明白花冤枉钱招人了，但放弃系统等于打自己的脸，往上报告高层也不好交代（公司规定每个高级人才辞职都要问责上司的）。

 

我不想背这个锅，顺着A领导去做讨得欢心也不给我加一分钱，还要为系统问题买单。然后，A领导和我的话更少了，推广使用我的开发平台，有任务丢给新人，然后新人不会的我来搞定。之前招聘高手来做Java平台许诺的十万奖金也没人再提。

 

如果选择表面维护遗留系统(实际用自己的平台)，十万奖金是可以向高层申请到，但考虑到一群”设计师“出力的情况，有一万到手就不错了。即使一万对于他们只是零钱，对于我是巨款，但有些事我做不到妥协。

 

 

 

发奋

 

马云说过，辞职只有两个理由。要么是钱给得不够，要么是心受委屈了。两个理由都有了，是时候该换个工作了。

 

不懂忽悠也不想学忽悠，只好修内功。上班有空就看技术书籍，下班也看，走亲戚也带着书，于是有了上面的事情：

 

------------------------------------------------------------------------------------------------

看完评论发现权限设计是一个经典的老生常谈问题。会的人胸有成竹、对权限问题不削一顾，不会的人还在苦苦思索，到处找代码。

初入门我先后用了吉日嘎啦、伍华聪、金色海洋等人的权限设计，那时他们争论很激烈，下篇把我的设计和代码发出来，让不会的人少走弯路。

设计基础：用户、角色、权限三大核心表，加上用户角色、角色权限两个映射表(用于给用户表联系上权限表)。这样就可以通过登录的用户来获取权限列表，或判断是否拥有某个权限。

物理学总喜欢不断抽象，试图建成大统一系统，比如牛顿力学是相对论在低速状态下的一个特例。软件思想也是如此，

任何权限的需求，都是为广义的用户分配角色，角色拥有广义的权限。角色是最重要的中枢，隐藏做幕后黑手，从不出现在业务代码里，用行话说就是解除了用户和权限的直接耦合。

角色把用户抽象化了，几百个用户变成成几个角色，用户->角色->权限写成通用判断权限的方法：currUser.IsHave(xx权限)。核心就是一个sql联表查询语句，查询条件为用户id。

例如：
部门权限：部门也是一种用户，建立 部门表、部门角色表。通用权限方法里加上 当前部门->部门所属角色->权限 
职位权限：职位也是一种用户，建立职位表、职位角色表，同上
菜单：也是一种权限，建立 菜单表、角色菜单表，就把菜单纳入了权限管理。通用权限方法里加上 角色列表->权限、菜单