關於自動化平台的動態菜單設計（二）
最近有一個很深刻的感受，那就是開發的中途被打斷，然後重新恢復上下文需要花費更多的時間，而如果中間間隔幾天，原來對於這個產品的認知和理解會立馬下降，這一點在我接觸資料庫的過程中感同身受。
資料庫的運維工作中，我喜歡啪啦啪啦的敲一大堆的命令，處理問題的時候，手完全能跟上自己的思路，而明顯的感受，周一敲命令的手感就差了很多，隔個雙十一過年的，會掉下一大截，所以這手藝活的頻度還是要保持。
自動化平台的事情，自己開發了幾個功能，更多是在平台的基礎架構和設計上。從把前後端打通，到後面能建設成一個基本的體系，腦子裡門清，但是要落實下來，一件一件，實屬不易。
比如我拿出現在的平台中的幾個截圖，可以簡單聊聊對於這個產品的一些理解。
比如對於元數據的管理，我看了很多的平台建設，也看到了很多的自動化平台，目前碰到的有兩個大的問題，一個是過度設計，一個是沒有設計。
過度設計是功能從開始就會過度解耦合，嚴格遵守三範式，一個看起來簡單的溝通要拆分出非常多的子表。
比如對於資料庫自動化平台來說，對於硬體層面的一些基礎數據如果能夠有相應的介面來打通，相對來說就不需要重新建設。
所以我對現有的元數據做了梳理，儘可能整合起來，一張表能表達清楚，絕對不用三張表。
那麼下面的圖裡有什麼改進的點呢？
第一個就是數據的自採集，如果我們有大量的基礎數據都需要手工錄入，那麼無形中就會增加操作的複雜度和接受程度，完全依賴人也是不靠譜的。
第二個就是給數據的擴展留有餘地，比如現在我把基礎元數據分為了物理層面，系統層面，資料庫層面，應用層面。在欄位定義上我就會特意的標識出來
第三個就是界面中還沒有增加的按鈕，目前的設計是增加的功能單獨分離出來了。這個目前沒有完全想好，其實可以放在一個統一的頁面中通過div的方式來實現。
第四個就是目前的搜索功能其實是完全通過前端的方式實現的。沒有做細粒度的搜索，但是能夠做到基本的匹配搜索。
第五個就是目前的使用其實分頁方案是把數據都查出來，在前端來實現分頁。和高性能中考慮的分頁是完全不同的，千兒八百的伺服器可能差別不大，量級一大，這個問題就會逐步成為性能問題。
第六個是資產數據的狀態其實是和數據的生命周期聯繫起來的，有些數據是不需要有修改許可權，或者你不能默認創建出一個故障伺服器。
當然在菜單的設計中，我是使用了動態菜單，即菜單和用戶是多對多的映射關係，實現的一個方向就是不同的用戶能看到不同的菜單，這樣便於隔離和統籌管理。
這個圖有什麼改進之處呢？
首先第一個是就是修改和刪除的許可權不明確，表格左邊的「菜單ID」如果點擊其實是可做修改的，但是從我的理解和使用習慣來說，這種方式比較隱晦，所以界面的設計風格還是更傾向於是第一種。即修改和刪除的方式都能有相應的按鈕來對應。
第二是界面的設計中，對於菜單的層級關係目前還沒想到更好的方式。
第三個對於增刪改的方式，有一種思路，第一種是統一使用div前端來顯示，在同一個頁面中完成，要麼就是在頁面間跳轉。從我的理解來說如果頁面的功能單一，我更傾向於是前端的JS+Ajax來推送數據，後端來推送JSON來回調。
下面這個圖是做數據的許可權校驗的時候，
我們可以根據下拉列表來得到一些許可權的信息，這個許可權信息該如何處理。如果許可權之前是1,2,3,5，現在選擇了1,2,4，那麼原來的許可權是要清掉，還是動態來適配。
還有許可權的信息顯示是把已有的許可權都勾選出來，避免重複勾選，而且設置為不可改變還是更加動態，使用兩個複選框來處理。
菜單和許可權在顯示的時候是不是可以滿足層級關係。
想了這麼多，準備都細化下，把這些都解決掉。
所以看到的一個簡單界面，細細打磨還是有很多的細節。後面給團隊整理一般平台開發手冊。
TAG:楊建榮的學習筆記 |