兒啊，你要努力，要是30多歲還像叔叔一樣學習，我和你爸就要喝西北風了

前兩天冬至(這邊流行冬至前兩日就開始吃一種像餃子的東西，誤以為那就是冬至)，很多親戚聚在一起吃飯。我拿著一本《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的地址，各種資料隨便訪問。

終於說服A領導，那個系統沒有必要使用了。當時我也注意到，”繼續發揮它的價值“這句話的深層含義，A領導也明白花冤枉錢招人了，但放棄系統等於打自己的臉，往上報告高層也不好交代（公司規定每個高階人才辭職都要問責上司的）。

我不想背這個鍋，順著A領導去做討得歡心也不給我加一分錢，還要為系統問題買單。然後，A領導和我的話更少了，推廣使用我的開發平臺，有任務丟給新人，然後新人不會的我來搞定。之前招聘高手來做Java平臺許諾的十萬獎金也沒人再提。

如果選擇表面維護遺留系統(實際用自己的平臺)，十萬獎金是可以向高層申請到，但考慮到一群”設計師“出力的情況，有一萬到手就不錯了。即使一萬對於他們只是零錢，對於我是鉅款，但有些事我做不到妥協。

發奮

馬雲說過，辭職只有兩個理由。要麼是錢給得不夠，要麼是心受委屈了。兩個理由都有了，是時候該換個工作了。

不懂忽悠也不想學忽悠，只好修內功。上班有空就看技術書籍，下班也看，走親戚也帶著書，於是有了上面的事情：

—————————————-

看完評論發現許可權設計是一個經典的老生常談問題。會的人胸有成竹、對許可權問題不削一顧，不會的人還在苦苦思索，到處找程式碼。

初入門我先後用了吉日嘎啦、伍華聰、金色海洋等人的許可權設計，那時他們爭論很激烈，下篇把我的設計和程式碼發出來，讓不會的人少走彎路。

設計基礎：使用者、角色、許可權三大核心表，加上使用者角色、角色許可權兩個對映表(用於給使用者表聯絡上許可權表)。這樣就可以通過登入的使用者來獲取許可權列表，或判斷是否擁有某個許可權。

物理學總喜歡不斷抽象，試圖建成大統一系統，比如牛頓力學是相對論在低速狀態下的一個特例。軟體思想也是如此，

任何許可權的需求，都是為廣義的使用者分配角色，角色擁有廣義的許可權。角色是最重要的中樞，隱藏做幕後黑手，從不出現在業務程式碼裡，用行話說就是解除了使用者和許可權的直接耦合。

角色把使用者抽象化了，幾百個使用者變成成幾個角色，使用者->角色->許可權寫成通用判斷許可權的方法：currUser.IsHave(xx許可權)。核心就是一個sql聯表查詢語句，查詢條件為使用者id。

例如：

• 部門許可權：部門也是一種使用者，建立 部門表、部門角色表。通用許可權方法里加上 當前部門->部門所屬角色->許可權
• 職位許可權：職位也是一種使用者，建立職位表、職位角色表，同上
• 選單：也是一種許可權，建立 選單表、角色選單表，就把選單納入了許可權管理。通用許可權方法里加上 角色列表->許可權、選單