为什么用代码生成代码？

说说我的情况,依旧是亘古不变的问题，人手不足、一个月要出东西，再加上懒得再沉浸在毫无意义的增删改查上，将主要精力集中在关键功能上，因为我本身全栈，所以关键节点基本上都清楚，有些问题可能超纲了前端范畴，老哥们领会精神就行

• 分析前端开发的变量和工作复杂度在哪里、本质上就是剔除非常规，归集常规，找不同

1.主要对页面功能有大致情况的了解,如果功能页功能布局与实现相对单一且有规律的占比1半以上,区分情况拆解

2. 细分下来其中空白的属于常规页、单表基本页（基本逻辑可考虑生成），有些交互功能比较复杂要调整、报表为配置型要溯源，但页面功能操作交互功能比较少

• 数据关键获取方式问题，从源码、页面、配置、规律入手

（1） 直接分析传染页（HTTP请求），好处在于轻易的能抓到字段名、字段、布局、字典、功能等核心要素，缺点在用jsp特性搞出来的一些东西没法溯源，另外一些动态功能会导致不可控因素增加 （2）分析源码渲染页（文件读取），基本能满足溯源和页面关键要素获取的条件

• 结合实际情况、选择相应的生成处理引擎

（1）之前有看elment-ui关于代码生成代码的内容，算是一个种子，在后来plop那种cli规则命令，但这种适应于量少，规范化标准cli的雏形,不太适合量大，情况复杂批量处理 （2）后来用node+ejs，分析后觉得情况合适,辅助正则能解决一部分问题，另外一部分表单部分就有差异了,正则有点儿力不从心，后来找了个cheerio类似于jq选择的功能，相关情况得到了满足 （代码还没来得及规整，将就看）

• 对比原功能与新开发接口适配、约定后续方式,其中关键要素如下

class PageViewModel {

//父业务编码
parentCode =''
//父业务名称
parentName=''
//当前业务编码,主要针对文件生成命名
code=''
//当前业务名称，描述备注等
name=''
//当前业务请求自定义controller
apiCode=''

/**
* 读取
*/
title=''//业务名称
keyid='id'//主键
columns=[] //列名称
ops=[]//操作
form=[]//表单
query=[]//查询
}
module.exports=PageViewModel

• 完成批量生成,划分情况做区分生成

最终完成关键要素的解析,当然单表和报表主要分析数据库的配置以及表获得关键要素，原理是一样的

最终获得了生成文件

和前几年的配置型页面的区别是什么？

之前常规做法往往是页面适配所有显示、用关键key做区分进行不同渲染，所有的相关关键元素都是走的通用数据库配置，这种你也不能说他不对，只能说在当时缺失解决了大批量页面配置化的问题，算是轻量级的BI原型，但在后期扩展功能的时候就有点儿拉跨，就跟现在提的低代码平台，本质是由流程那套衍生出来的，只不过换了中提法和设计思路、就项目后期延展性来讲，有改动灵活频繁特性的项目并不适用。 生成的方式相当于前期做了预演，提供一个基础的插座，让后期的改动能在一个顺滑的基础上进行，省去不必要的拷贝及不统一，让规律性的东西沉淀下来，不会关注你用A框架，B框架，A约定,B约定,适配新的模板即可。

适应什么情况？

• 重复性基础性的工作提前准备，集中精力做复杂关键性的功能，人力始终靠不住,而且现在前后端的拉扯，磨人心神，固执不容易被说服是每个优秀程序必备的特质,但也是沟通过程中最大的障碍，我们把拉扯放在关键处
• 传统老项目升级改造，因为一般规律就是一个模板，发动Contrl CV大法,所以改造是有可行性的，当然服务端的生成也很容易，最重要的解决基础插座的问题，并不是解决所有的问题，该特殊处理的问题，添加逻辑即可，这个观念很重要，不然沟通的基础就不存在了，你说服不了固执的老哥们。
• 新业务表的设计由老司机负责，比较规范，服务和页面后行

解决了什么问题？

• 以上聊的，主要也是基于无奈和懒的心态，开发的时间久了，真的是对一般性的功能提不起啥兴趣，索然无味
• 再有就是，一般性的工作总结成规律之后，所有的重复劳动也就有了替代工具，软件开发的目的不就是减少重复劳动嘛，没必要作为一个开发者还在重复劳动，花更多的时间去学习不香嘛

获得了什么？

如果你看过之前的内容应该有所了解，关于生成这块其实尝试并不少，至于为什么会尝试这么多次，也是根据技术发展带来的便利，解放了更多的灵活性同步来的，互联网中场，单体的能量有限，多几个机器小助手，你的眼界能更开阔，加油吧打工人 PS: 随手来个赞吧老哥