> 之前有序言章节<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：“既然都是类似代码，那有没有可能让开发的童鞋歇会呢？”

后端甩锅王：“................#$#%^^%@#!”

原文地址：https://www.cnblogs.com/webmote31/p/14878646.html