最近在做物流許可權系統的重構，回看梳理下流程，算是對這一工作的總結吧
表結構設計：
使用者，角色，許可權及兩兩之前關係，共五張表，再加乙個使用者與倉庫的繫結關係表(業務需要)
許可權認證框架：
使用shiro,最近在做的一套新系統有用到，使用可以參考，而且相比springsecurity更輕量
資料遷移：
暫時有兩套方案：
1：不做資料遷移，系統分兩次上線，第一次先上線新許可權的配置頁面，由業務方與產品配置，等配置資料有了之後，再上線全部內容
2：做資料遷移，一次上線，存在的問題：舊的許可權系統表設計複雜，無注釋，理解起來需要時間
與同事討論後確認了第二種方案，但不做全量的資料遷移，開發遷移使用者資料及配置許可權資料，在測試環境產品將角色定義及使用者與角色的關係配置好，上線前將這批資料初始化即可
準備階段：
1.學習shiro框架，熟悉其核心原理，做到對開發過程心中有數，出了問題可以即時排查與解決
2.了解舊系統的**（舊系統是使用springsecurity+session+memcache），看下有沒有潛在的坑，如舊系統的接囗裡是如果獲取使用者資訊的，要怎麼相容等等
3.對細節問題與產品確認，如允許多地登入嗎，就是兩台電腦同時登入乙個賬號，登入後修改許可權，相關許可權要跟著變化嗎等
技術評審：
主要是開會與產品，測試，組長同步這次需求的設計，改動點等，與大家達成共識
開發階段：
只要前期的方案沒問題，準備也夠充分，這個階段是很快樂的，記得寫單元測試噢
這個階段沒什麼特別的，開發可以看下測試用例是否齊全，對重點測試的場景要給測試提醒，對不容易測試的點，如token過期可以適當提供後門
略
機房收費系統 專案回顧與重構展望
所有曾經逼的你想上吊的bug，完成以後，也不過就是幾行 的簡單問題。就像這無常的人生，懦弱者總因它猛虎的姿態被嚇退，而只有勇者才會發現它猙獰面孔下紙糊的實質 困難像彈簧，你弱它就強。今天，以勝利者的姿態俯視它，會發現它不但本質簡單，鏈結構也十分簡單。接下來，簡單的分析一下這個專案。機房收費系統實現的...
c 回顧 protect 許可權
類似於private許可權，protect的許可權對於類的使用著來說是不可見的 類似與pubic許可權，protect的許可權對於基類的派生類和友元是可見的 無法通過派生類訪問基類物件的protect的成員 第三條就保證了無法通過派生類來繞過protect許可權 例如 include class b...
重構 C 登入許可權的判別
針對不同的使用者，使用者許可權是不一樣的，不同許可權的使用者登入系統之後顯示的介面也應該不同，這就需要加入使用者許可權的判別了。主介面 判斷使用者許可權 entity.userinfo user new entity.userinfo user.userid frmlogin.globaldata1...