我理解的低代码，真的增效了吗？

看了是市面上至少10款以上的低代码，绝大部分都实现了电脑端的低代码形式，不论是用语言java，c#，php等都存在有，详细不讨论用哪种高效或者灵敏，主要想写的是低代码实现的整体思路。废话不多说了，直接正题，其实我总结出来当前低代码无外乎其实只分为两种实现形式。

第一种、后端效劳端组件形式

后端效劳的组件形式，用过c#的winform大家就应该很能理解，同样的实现方式，就是自定义很多html的根底控件，在后端效劳端写自定义控件。

前端给到用户新建表单业务的时候，让用户去选择控件类型，对应在去设置控件的属性。当然在这个配置的过程中，是没有可视化预览页面的，根本上都是配置完成后保管后，才干到对应的页面去刷新查看效果。
或者还有另外一种配置方式，就是让配置表单人员去下载一个exe的装置包，在这个单机版软件里面去配置，完全是c# 的winform配置体验。
优缺点分析

优点：

• 阅读器兼容性强
  

都是用的原生html根底控件，css2等，阅读器根本都支持

• 电脑端和挪动端只需一套代码
  

前端停止了后端化，只需要在后端做匹配即可。
缺点：

• 交付或管理员配置业务体验差
  

没有实时的预览页面，配置效率低，来回返工配置

• 用户使用软件体验一般
  

用的软件技术太陈旧，用户有对比，体验感不友好。

• 需求兼容差
  

新需求，新属性就必需要改动后端，晋级系统，无法及时个性化修改

• 二次开发难度大
  

框架架构形式复杂，技术人员上手周期很长，程序员使用的技术无法平移新公司

• 太依赖技术开发人员
  

很多时候，一旦配置出问题或者数据检查，都必需依靠懂这个技术底层的人员去检查，无法平移到运维去协调检查
第二种、前端化组件形式

这个就很好理解，就是用第三方的前端框架技术，比如Vue、React‌、‌Angular‌等，这种都有很多开源且方便二开的UI，如下图，当时我们选择的是vue的elementui，我们不论是通用的组件还是个性化定制组件，都是以vue2.0技术为前端根底，来停止定制开发。

同时我也看了市面上很多，他们也是这种形式，当然，根本上他们都是自己写的前端框架底层，毕竟几年前很多前端框架都还不成熟，或者是用的之前的历史框架。
优缺点分析

缺点：

• 历史框架vue2.0，无法适配到鸿蒙app
  

需要做版本晋级vue3.0才干做鸿蒙的app。
优点：

• 交付或管理员配置效率高
  

在配置业务功能时，可实时预览配置效果，进步配置效率，降低配置返工率

• 二次开发很容易
  

二次开发也提供配置开发平台，简单或者通用的接口直接运维配置即可

• 对开发人员要求低
  

整体底层框架构建很简单，只需要看懂一个控件的逻辑，就能自己上手开发组件

• 技术框架很群众
  

前端化后，绝大部分的人员都很容易学，换而言之，懂前端的js，css,vue就能上手

• 用户体验群众化
  

如今很多系统，不论是电脑端还是挪动端，绝大部分新系统都是用的最近两三年新的框架，所以在使用体验上坚持了同步，不会有太大的偏向

• 配置可读性强
  

以前开发一个功能，必需要新建一个页面，不论这个页面以文件的方式还是以数据库字段方式，都必需完全寄存整个页面，而当前如今的形式是只寄存页面组件的json文件即可，如下图：

总结

我理解的低代码其实就是软件公司的一个工具，我们不时给这个工具赋能。
第一阶段（完全技术开发）：100%功能都是技术开发人员
第二阶段（低代码1.0）：60%功能施行人员配置（表单功能配置），40%个性功能技术开发（、简报、报表、接口）
第三阶段（低代码2.0）：85%功能施行人员配置（表单功能配置、简报、报表、接口），15%个性化技术开发（个性化需求：比如前后端事件逻辑-发短信、新不规则页面、底层优化兼容）
第四阶段（低代码3.0）：90%功能施行人员配置（表单功能配置、简报、报表、接口、前后端事件），10%个性化技术开发（个性化需求：底层优化兼容）
整体思路就是，不时的根据自己所做的软件行业，不时去总结用户的个性化需求，提炼共同点，一点一点去出方案处置。我相信只要这样才干真正的去降低自己内部软件开发的本钱，把更多的时间用在开掘客户需求上，打磨自己的软件底层。
当然我上面分析的主要是技术部门的整体规划，我想的是只要这样，我们的商务才干更有底气去谈项目。
如今都在说降本增效，是降本，还是增效，我们公司整体的战略就是增效，把效率进步了，其实也就降本了，我们更愿意一起努力去进步公司内部的流转效率。