> 之前有序言章节<Vue中路由到一个公共组件，然后根据路径中是否存在文件动态加载组件>，已经是一个雏形了。而现在，重新梳理下，我们要做的是让前端工程师不用上班了，哈哈，这么贴心的后端哪里找？
1、终极需求
产品经理A：“经常有些需求，并不是那么复杂，可能仅仅是增删改查，做些验证，为啥总要时间开发？”
后端甩锅王： “我开发很快的，但是！ 每次做需求的时候，总需要前端童鞋的协助，他们总是很忙~~~”
产品经理A："既然都是类似代码，那有没有可能让开发的童鞋歇会呢？"
后端甩锅王心里一万头神兽掠过,这是要 让程序员不写代码啊!, 不写代码的程序员还是程序员吗?
好吧,我就静静的看你装B!
后端甩锅王：“我想到了个方案，可以 让前端程序员不写代码!”
产品经理A：“好棒耶，去干, ta!”
2、组件规划
既然决定不需要前端人员参与，就能搞定一个模块。 那我们就做个通用模块的增删改查就好了。
当然根据产品经理的“需求的发展”，也许需要多个不同类型的组件，满足各类奇葩需求。
我们就用最简单的列表（按钮），同页面增删改查方式实现一个。
大概的界面如下：
一个模块需要的基本的功能都有了:
- 增加(增加按钮,弹出页面)
- 修改(修改按钮,弹出页面)
- 删除(弹出确认提示)
- 搜索,可以搜索定制列
- 分页,展示多页
2.1 面向约定开发
根据这些功能,我们提取变化的地方到配置中。
配置里尽量按照约定来约束后端的开发 ， 仅把模块名视作变化量。
- 接口命名按照增删改查的动作+模块名 来定义
- 提供公共接口，入参：模块名，出参：该模块的下配置（列表、form表单）
- 后端配置 前端页面的路由，并由前端整合到路由表内。
这里路由信息 参见序言文章.
views/common/index就是我们的公共入口
{
path: '/test',
component: Layout,
hidden: false,
meta: { title: 'test', icon: 'dashboard' },
children: [{
path: 'testa',
name: 'testa',
component: () => import('@/views/common/index'),
meta: { title: 'test1', icon: 'dashboard' }
},
{
path: 'testb',
name: 'testb',
component: () => import('@/views/common/index'),
meta: { title: 'test2', icon: 'dashboard' }
}
]
},
2.2 预留前端开发入口
为了给前端童鞋留条活路（应对复杂的需求变化），我们心存善良的留下了前端参与的方式。
如果前端童鞋开发了该模块的功能,那我们就客气的使用吧。
var path = this.$route.fullPath
try{
this.realCompoonent = require(`@/views${path}`).default
//this.$router.push(this.realCompoonent)
}
catch(ex){
console.log(`load sub com [${path}] failed. ${ex}`)
this.realCompoonent = null
}
2.3 减少Ctrl+C\V
因为预留了扩展接口，前端童鞋又可以快乐的 Ctrl+C，Ctrl+V了，有没有什么办法救救孩子们？
嗯嗯，明白了，虽然需要定制，可能也只是某些部分吧，那我们能不能多预留几个slot呢，嗯嗯，这种方式是可以的。
我们采用了另外的方式，引入了mixList.js ,在这里定义了公共组件大部分功能, 扩展的瘦,仅需要引用 mixins:[mixList],即可继承所有的方法, 看那个方法事件不满意,都可以重载覆盖它们,.
嗯嗯,好了吧,
2.4 动态加载配置
按照2.1章节,我们已经预定了所有的配置和模块名强相关,那么我们需要做的就是怎么解析到 模块名,并传送给公共组件?
眼见的童鞋们,应该发现了路由路径上就是最好体现模块名的地方,那我们就约定路径的前2个节点为模块名,.
把模块名组织好,传给后台, 然后一切的配置都由后台决定了。
至此，前端的工程师们可以躺平了！
3. 后端开发
之前已经聊过,后端只需要按照约定开发相应的接口即可。
后端甩锅王：“做完了这个需求，我咋发现我自己被套路了，这下需求再完不成，就没办法甩锅前端了！oooop，我要失业了！”
当然开发这个需求还是不容易的,后端童鞋可以收藏下,毕竟本次也没法一次写完,后续会不断更新。
大致先欣赏下前端的配置界面。
3.1后端表设计
- 先定义一个模块全局表
- 定义列表配置表
- 第三个就是form表单配置表
最后一列可以保存为json格式的数据,这样每个控件都有了自己可以定的属性了。
看到这里的童鞋，祝贺你，你已经进入了PASS设计的领域。
3.2 后端接口开发
接口仍在开发中，相信从数据库的设计，童鞋们应该可以自己动手撸代码了。
> 前端工程师们,别慌,你可以顺便做做PASS平台的开发了!
4.后记
产品经理A：“经常有些需求，并不是那么复杂，可能仅仅是增删改查，做些验证，为啥总要时间开发？”
后端甩锅王： “我要写代码才能完成啊？”
产品经理A：“既然都是类似代码，那有没有可能让开发的童鞋歇会呢？”
后端甩锅王：“................#$#%^^%@#!”
