关于自动化平台的动态菜单设计（二）

最近有一个很深刻的感受，那就是开发的中途被打断，然后重新恢复上下文需要花费更多的时间，而如果中间间隔几天，原来对于这个产品的认知和理解会立马下降，这一点在我接触数据库的过程中感同身受。

数据库的运维工作中，我喜欢啪啦啪啦的敲一大堆的命令，处理问题的时候，手完全能跟上自己的思路，而明显的感受，周一敲命令的手感就差了很多，隔个双十一过年的，会掉下一大截，所以这手艺活的频度还是要保持。

自动化平台的事情，自己开发了几个功能，更多是在平台的基础架构和设计上。从把前后端打通，到后面能建设成一个基本的体系，脑子里门清，但是要落实下来，一件一件，实属不易。

比如我拿出现在的平台中的几个截图，可以简单聊聊对于这个产品的一些理解。

比如对于元数据的管理，我看了很多的平台建设，也看到了很多的自动化平台，目前碰到的有两个大的问题，一个是过度设计，一个是没有设计。

过度设计是功能从开始就会过度解耦合，严格遵守三范式，一个看起来简单的沟通要拆分出非常多的子表。

比如对于数据库自动化平台来说，对于硬件层面的一些基础数据如果能够有相应的接口来打通，相对来说就不需要重新建设。

所以我对现有的元数据做了梳理，尽可能整合起来，一张表能表达清楚，绝对不用三张表。

那么下面的图里有什么改进的点呢？

第一个就是数据的自采集，如果我们有大量的基础数据都需要手工录入，那么无形中就会增加操作的复杂度和接受程度，完全依赖人也是不靠谱的。

第二个就是给数据的扩展留有余地，比如现在我把基础元数据分为了物理层面，系统层面，数据库层面，应用层面。在字段定义上我就会特意的标识出来

第三个就是界面中还没有增加的按钮，目前的设计是增加的功能单独分离出来了。这个目前没有完全想好，其实可以放在一个统一的页面中通过div的方式来实现。

第四个就是目前的搜索功能其实是完全通过前端的方式实现的。没有做细粒度的搜索，但是能够做到基本的匹配搜索。

第五个就是目前的使用其实分页方案是把数据都查出来，在前端来实现分页。和高性能中考虑的分页是完全不同的，千儿八百的服务器可能差别不大，量级一大，这个问题就会逐步成为性能问题。

第六个是资产数据的状态其实是和数据的生命周期联系起来的，有些数据是不需要有修改权限，或者你不能默认创建出一个故障服务器。

当然在菜单的设计中，我是使用了动态菜单，即菜单和用户是多对多的映射关系，实现的一个方向就是不同的用户能看到不同的菜单，这样便于隔离和统筹管理。

这个图有什么改进之处呢？

首先第一个是就是修改和删除的权限不明确，表格左边的“菜单ID”如果点击其实是可做修改的，但是从我的理解和使用习惯来说，这种方式比较隐晦，所以界面的设计风格还是更倾向于是第一种。即修改和删除的方式都能有相应的按钮来对应。

第二是界面的设计中，对于菜单的层级关系目前还没想到更好的方式。

第三个对于增删改的方式，有一种思路，第一种是统一使用div前端来显示，在同一个页面中完成，要么就是在页面间跳转。从我的理解来说如果页面的功能单一，我更倾向于是前端的JS+Ajax来推送数据，后端来推送JSON来回调。

下面这个图是做数据的权限校验的时候，

我们可以根据下拉列表来得到一些权限的信息，这个权限信息该如何处理。如果权限之前是1,2,3,5，现在选择了1,2,4，那么原来的权限是要清掉，还是动态来适配。

还有权限的信息显示是把已有的权限都勾选出来，避免重复勾选，而且设置为不可改变还是更加动态，使用两个复选框来处理。

菜单和权限在显示的时候是不是可以满足层级关系。

想了这么多，准备都细化下，把这些都解决掉。

所以看到的一个简单界面，细细打磨还是有很多的细节。后面给团队整理一般平台开发手册。