我眼中的低代码（一）：什么是低代码？

低代码是什么？

这个问题，我最近一直在思考，我是一个个开（算是一个全栈），最近在各种文章和项目中不断看到低代码，low code等相关名词。由此便生出了不小的兴趣。

从多个平台多个项目不断的来看。出现的原因有以下几点：

1. 前端人员太少：是的，你没看错，低代码出现最大的原因是因为前端人员太少或者成本太高造成的，需要一个低代码平台来降低一个或者多个项目创建和维护工作的工作量和复杂程度。
2. 统一UI交互规范：现在一个前端项目动则几G，更不用说大型的项目的大小了，一个朋友给我说，他们有一个平台，32G的大小，在拆成微服务后最大的也有3G的体积。其中各种库，包，插件，已经让主创团队无法把握了。因为厂子比较大，多个团队协作，几十个人玩这一个项目，人来人去，水平有高有低，UI的规范，库的内容，已经完全无法确认重复和标准。所以需要一个子团队主力基础ui组件的开发和维护工作 ，其他团队只进行业务逻辑的开发和维护工作，这就带来了一个问题，怎么让其他团队能按照标准来开发和维护？
3. 开发门槛 ：目前企业信息化非常快，常常一个任务还没完成，基于此任务的任务就已经出现多个。但是与之相对的是开发团队人员的数量和质量。所以这就有一个想法，让客户（使用者）参与进来。但是客户不懂技术，我们需要让他们点点点，就能完成他们需求的业务逻辑。
4. 前端更新太快了：我有一个以前的项目，大概有个6年左右的历史，里面有JQ，vue1，vue2，EasyUI等各种前端的库，其中有有些库在更新，但是里面有多个版本比如：jqxxx，另外还有很多库已经不再更新了。现在每次想把他重构一次，然后的工作就是：坐下->打开项目->看代码->放弃。所以项目需要一个方案或者标准，对现在的项目进行抽象，将其包装为JSON或者其他对象，然后用这些高级集合体，去转为目标对象。
5. 其他还有很多的原因：跨团队/公司协作，业务需求（工作流）等等。

低代码的适用范围

目前来看，低代码平台的适用范围主要是取决于各个项目的设计和整体设计规范的。

有的是不适于 大量定制 UI ， 极为复杂或特殊的交互 ；

有的对非开发文员有较高的门槛；

有的是因为协议和商业平台等的限制；

低代码目前的现状

各大平台项目，尚未见到统一或者说具有强优势的标准。

低代码平台参考

1. Extjs：你敢相信么，他在0几年就已经初步完成了低代码的初步概念和工作，虽然没有以低代码来宣传，其实以当前市面上我见到各种平台和项目来说，它是最强的。以其特殊的加载方式和基础组件库，完成了MVVM/低代码/微前端等等的工作。除了收费，简直完美。
2. amis：一个目前我觉得仍在进步中的低代码框架，我个人觉得最大的缺点是函数要写成字符串的形式，这个实在是太蛋疼了，希望可以像ext一样的进行以类而不是json的形式进行程序的加载。但是瑕不掩瑜，amis真的很适合在低代码平台的搭建。相比其他的框架有：现成的可视化编辑器，远端加载等优点。
3. J2Paas ：这是一个相对较成熟的项目,缺点是和后端绑定太深了，我觉得一个优秀的低代码框架最应该做的的是与后端无关。当然这是一个前后端一体化的项目，所以这也是此类系统的优点，拿来就能用。
4. 还有其他的很多低代码项目和框架就不一一列举，上面三个是目前我觉得值得拿来研究，也可以看到代码的几个低代码平台。

本文如有您觉得不合适的地方请回复，我会及时改正。