關於自動化平臺的動態選單設計(二)

 

最近有一個很深刻的感受，那就是開發的中途被打斷，然後重新恢復上下文需要花費更多的時間，而如果中間間隔幾天，原來對於這個產品的認知和理解會立馬下降，這一點在我接觸資料庫的過程中感同身受。

資料庫的運維工作中，我喜歡啪啦啪啦的敲一大堆的命令，處理問題的時候，手完全能跟上自己的思路，而明顯的感受，週一敲命令的手感就差了很多，隔個雙十一過年的，會掉下一大截，所以這手藝活的頻度還是要保持。

自動化平臺的事情，自己開發了幾個功能，更多是在平臺的基礎架構和設計上。從把前後端打通，到後面能建設成一個基本的體系，腦子裡門清，但是要落實下來，一件一件，實屬不易。

比如我拿出現在的平臺中的幾個截圖，可以簡單聊聊對於這個產品的一些理解。

比如對於後設資料的管理，我看了很多的平臺建設，也看到了很多的自動化平臺，目前碰到的有兩個大的問題，一個是過度設計，一個是沒有設計。

過度設計是功能從開始就會過度解耦合，嚴格遵守三正規化，一個看起來簡單的溝通要拆分出非常多的子表。

比如對於資料庫自動化平臺來說，對於硬體層面的一些基礎資料如果能夠有相應的介面來打通，相對來說就不需要重新建設。

所以我對現有的後設資料做了梳理，儘可能整合起來，一張表能表達清楚，絕對不用三張表。

那麼下面的圖裡有什麼改進的點呢？

第一個就是資料的自採集，如果我們有大量的基礎資料都需要手工錄入，那麼無形中就會增加操作的複雜度和接受程度，完全依賴人也是不靠譜的。

第二個就是給資料的擴充套件留有餘地，比如現在我把基礎後設資料分為了物理層面，系統層面，資料庫層面，應用層面。在欄位定義上我就會特意的標識出來

第三個就是介面中還沒有增加的按鈕，目前的設計是增加的功能單獨分離出來了。這個目前沒有完全想好，其實可以放在一個統一的頁面中通過div的方式來實現。

第四個就是目前的搜尋功能其實是完全通過前端的方式實現的。沒有做細粒度的搜尋，但是能夠做到基本的匹配搜尋。

第五個就是目前的使用其實分頁方案是把資料都查出來，在前端來實現分頁。和高效能中考慮的分頁是完全不同的，千兒八百的伺服器可能差別不大，量級一大，這個問題就會逐步成為效能問題。

第六個是資產資料的狀態其實是和資料的生命週期聯絡起來的，有些資料是不需要有修改許可權，或者你不能預設建立出一個故障伺服器。

當然在選單的設計中，我是使用了動態選單，即選單和使用者是多對多的對映關係，實現的一個方向就是不同的使用者能看到不同的選單，這樣便於隔離和統籌管理。

這個圖有什麼改進之處呢？

首先第一個是就是修改和刪除的許可權不明確，表格左邊的“選單ID”如果點選其實是可做修改的，但是從我的理解和使用習慣來說，這種方式比較隱晦，所以介面的設計風格還是更傾向於是第一種。即修改和刪除的方式都能有相應的按鈕來對應。

第二是介面的設計中，對於選單的層級關係目前還沒想到更好的方式。

第三個對於增刪改的方式，有一種思路，第一種是統一使用div前端來顯示，在同一個頁面中完成，要麼就是在頁面間跳轉。從我的理解來說如果頁面的功能單一，我更傾向於是前端的JS+Ajax來推送資料，後端來推送JSON來回撥。

下面這個圖是做資料的許可權校驗的時候，

我們可以根據下拉選單來得到一些許可權的資訊，這個許可權資訊該如何處理。如果許可權之前是1,2,3,5，現在選擇了1,2,4，那麼原來的許可權是要清掉，還是動態來適配。

還有許可權的資訊顯示是把已有的許可權都勾選出來，避免重複勾選，而且設定為不可改變還是更加動態，使用兩個核取方塊來處理。

選單和許可權在顯示的時候是不是可以滿足層級關係。

想了這麼多，準備都細化下，把這些都解決掉。

所以看到的一個簡單介面，細細打磨還是有很多的細節。後面給團隊整理一般平臺開發手冊。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-2152361/，如需轉載，請註明出處，否則將追究法律責任。