看了是市面上至少10款以上的低代码，绝大部分都实现了电脑端的低代码模式，不管是用语言java，c#，php等都存在有，具体不讨论用哪种高效或者灵活，主要想写的是低代码实现的整体思路。废话不多说了，直接正题，其实我总结出来当前低代码无外乎其实只分为两种实现模式。
第一种、后端服务端组件模式
后端服务的组件模式，用过c#的winform大家就应该很能理解，同样的实现方式，就是自定义很多html的基础控件，在后端服务端写自定义控件。
前端给到用户新建表单业务的时候，让用户去选择控件类型，对应在去设置控件的属性。当然在这个配置的过程中，是没有可视化预览页面的，基本上都是配置完成后保存后，才能到对应的页面去刷新查看效果。
或者还有另外一种配置方式，就是让配置表单人员去下载一个exe的安装包，在这个单机版软件里面去配置，完全是c# 的winform配置体验。
优缺点分析
优点：
1）浏览器兼容性强
都是用的原生html基础控件，css2等，浏览器基本都支持
2）电脑端和移动端只需一套代码
前端进行了后端化，只需要在后端做匹配即可。
缺点：
1）交付或管理员配置业务体验差
没有实时的预览页面，配置效率低，来回返工配置
2）用户使用软件体验一般
用的软件技术太陈旧，用户有对比，体验感不友好。
3）需求兼容差
新需求，新属性就必须要改动后端，升级系统，无法及时个性化修改
4）二次开发难度大
框架架构模式复杂，技术人员上手周期很长，程序员使用的技术无法平移新公司
5）太依赖技术开发人员
很多时候，一旦配置出问题或者数据检查，都必须依靠懂这个技术底层的人员去检查，无法平移到运维去协调检查
第二种、前端化组件模式
这个就很好理解，就是用第三方的前端框架技术，比如Vue、React、Angular等，这种都有很多开源且方便二开的UI，如下图，当时我们选择的是vue的elementui，我们不管是通用的组件还是个性化定制组件，都是以vue2.0技术为前端基础，来进行定制开发。
同时我也看了市面上很多，他们也是这种模式，当然，基本上他们都是自己写的前端框架底层，毕竟几年前很多前端框架都还不成熟，或者是用的之前的历史框架。
优缺点分析
缺点：
1）历史框架vue2.0，无法适配到鸿蒙app
需要做版本升级vue3.0才能做鸿蒙的app。
优点：
1）交付或管理员配置效率高
在配置业务功能时，可实时预览配置效果，提高配置效率，降低配置返工率
2）二次开发很容易
二次开发也提供配置开发平台，简单或者通用的接口直接运维配置即可
3）对开发人员要求低
整体底层框架构建很简单，只需要看懂一个控件的逻辑，就能自己上手开发组件
4）技术框架很大众
前端化后，绝大部分的人员都很容易学，换而言之，懂前端的js，css,vue就能上手
5）用户体验大众化
现在很多系统，不管是电脑端还是移动端，绝大部分新系统都是用的最近两三年新的框架，所以在使用体验上保持了同步，不会有太大的偏差
6）配置可读性强
以前开发一个功能，必须要新建一个页面，不管这个页面以文件的方式还是以数据库字段方式，都必须完全存放整个页面，而当前现在的模式是只存放页面组件的json文件即可，如下图：
总结
我理解的低代码其实就是软件公司的一个工具，我们不断给这个工具赋能。
第一阶段（完全技术开发）：100%功能都是技术开发人员
第二阶段（低代码1.0）：60%功能实施人员配置（表单功能配置），40%个性功能技术开发（、简报、报表、接口）
第三阶段（低代码2.0）：85%功能实施人员配置（表单功能配置、简报、报表、接口），15%个性化技术开发（个性化需求：比如前后端事件逻辑-发短信、新不规则页面、底层优化兼容）
第四阶段（低代码3.0）：90%功能实施人员配置（表单功能配置、简报、报表、接口、前后端事件），10%个性化技术开发（个性化需求：底层优化兼容）
整体思路就是，不断的根据自己所做的软件行业，不断去总结用户的个性化需求，提炼共同点，一点一点去出方案解决。我相信只有这样才能真正的去降低自己内部软件开发的成本，把更多的时间用在挖掘客户需求上，打磨自己的软件底层。
当然我上面分析的主要是技术部门的整体规划，我想的是只有这样，我们的商务才能更有底气去谈项目。
现在都在说降本增效，是降本，还是增效，我们公司整体的战略就是增效，把效率提高了，其实也就降本了，我们更愿意一起努力去提高公司内部的流转效率。
