前语
本文是笔者在团队内部做共享收拾的材料的一部分，本次共享首要是站在一个服务端开发的视角对（前端）低代码渠道的一些调研，现已剔除了一些敏感数据和信息，可定心食用。
太阳底下无新事
Dreamweaver -> Low-Code
将时钟拨回到 20 年前，那个时候的开发者关于 html/css/js 还处在望而生畏的阶段，Dreamweaver 的出现似乎让他们看见了曙光。经过简略的拖拽就能够实时预览编列的页面，点击按钮就能够主动生成对应的前端代码，装备好机器信息就能够一键布置拜访…… 这些特性让无数开发者趋之若鹜，然后现在他的境况
现如今，Dreamweaver 简直现已退出了历史舞台，但 Low-Code 似乎又有卷土重来的痕迹……
Low-Code 是什么？
A low-code development platform (LCDP) is software that provides a development environment used to create application software through graphical user interfaces and configuration instead of traditional hand-coded computer programming.
一句话归纳便是 用 GUI+装备替代传统手工编码 技能上，完结低代码渠道的关键要素是模型驱动规划、代码主动生成和可视化编程，经过这些手法来隐藏基层的代码细节。
更激进的—— No-Code（零代码）
Low-Code 更激进的演进方向是 No-Code，首要的差异点如下：
-
渠道用户：任何事务人员都能运用无代码渠道，而低代码渠道面向开发者（虽然专业要求不那么高）
-
中心规划：无代码渠道倾向于让用户经过拖拽或简略的表达式来操作完结运用规划，而低代码渠道更倾向于经过人工编码来指定运用程序的中心结构
-
用户界面：无代码渠道为了简化运用规划，一般只支撑内置的 UI 库，而低代码渠道可能会供给更灵活的 UI 选项，但价值是需求额定编码，运用上的复杂性有所增加
为什么目前低代码只在前端范畴很火？
被资源化的前端开发者
作业量大，重复性作业较多，因此出产功率成为了必须要处理的问题。
最好的处理办法是经过东西化、主动化的方式提高出产功率，打破前端资源瓶颈。
前端的技能体系满足敞开
相较于 Native/服务端，前端的技能体系更敞开，前端 low-code 产品都能运用到现有的任何前端运用程序中
前端的运用体系更加工程化
吃饱了才有力气瘦身，只要处理了温饱问题，才能转而追求更高的出产功率。
现阶段，前端的工程化益发老练 CLI -> GUI 客户端 -> Web IDE 工程化带来的优点是，编码层面的功率提高现已达到极致，更进一步的出产功率提高需求变革式的打破。
现在的 Low-Code 和 20 年前的 Dreamweaver 有什么差异？
单从表面上看，可视化地主动生成一些代码的确没有太大差异，内涵的实质性差异在于：
-
方针场景不同：Dreamweaver 更多地聚焦前端开发场景，而在 low-code 开发渠道中，前端仅仅完好运用程序的一部分，服务端数据、路由、逻辑流程等都需求考虑在内
-
可视化操作粒度不同：现代 low-code 渠道通常有组件、区块、页面、模板等多级复用笼统，Dreamweaver 只面向 HTML 原生标签
-
工程链路齐备程度不同：Dreamweaver 仅覆盖到开发、预览、布置（FTP 上传）环节，而现代 low-code 渠道大多涵盖了完好的生命周期，包括发布前的调试、测验，发布后的监控运维等各个环节
跟着前端工程体系的一路演进，现代的 low-code 渠道充分考虑了模块复用、生态接壤、前后端联动、工程管理等重要因素，在老练度和开发功率方面比较 Dreamweaver 都有了质的腾跃。
阿里巴巴低代码引擎（ALCE）
考虑到数据安全，这一部分在原文基础上做了较多改动，根据集团现已开源的信息做介绍，详情可跳转至官网地址 lowcode-engine.cn
低代码渠道的底层是低代码引擎，引擎中心在于灵活对接丰富的高质量物料，结合一个优雅、高效的编列引擎，让一个泛技能线的同学用所见即所得的方式，完结页面的建立、布置，完结快速自交付的闭环，达到预期方针。
其中引擎 SDK，包括 4 个首要模块，即入料、编列、渲染、出码。
-
入料：将物料，按照《低代码引擎物料协议规范》进行元数据描绘后，导入到规划器中，成为一个可被编列的物料；
-
编列：将规划器中的所有物料，进行布局设置、组件设置(CRUD)、交互设置(JS 编写/逻辑编列)后，形成符合事务诉求的 schema 描绘，此 schema 遵从 《低代码引擎建立协议规范》；
-
渲染：将编列得到的 schema 渲染成可交互的页面；
-
出码：将编列得到的 schema 转成实在的代码结构，比如 Recore / Ice / Remax / Umi 等运用框架结构；
体会低代码开发后的感受
黑盒开发
因为屏蔽了一些代码，接手的人不知道为什么这个组件在这里，为什么会有这样的作用。心路历程根本如下
我写了一段代码，只要我和编译器/解释器看得懂。
过了一段时刻，就只要编译器/解释器看得懂了。
我用低代码渠道拖了一些”控件”，最后我发现只要浏览器看得懂。
学习本钱并不低
-
需求有必定的前端常识（话说现在会 React 这类框架根本现已是必备要求了吧）但是问题是，有这些才能的根本上也能够开发一个简略的页面了
-
文档不够详细，经常需求提 issue 或者问人
-
第三方组件与生态并不完善
迭代功率提高不明显
虽然在画页面、适配款式等方面，低代码渠道有非常大的优势，但由于学习本钱、黑盒开发等原因，导致在开发时问题的排查功率低下，开发的幸福感大打折扣。
如果官方供给的组件库不满足事务需求时，开发自定义组件/运用第三方组件的本钱和手动编写代码相差无几。
对低代码渠道的一些考虑
服务端编写前端代码的痛点是什么？
-
前端技能栈多&杂，不知道学习哪一个
-
重复性多做较多，布局难适配，css 编写头疼
上面两个问题，低代码渠道能够处理，但是现有的前端技能也能够处理
可视化编程的功率必定比写代码功率高？
编程本质上是一种表达，它的东西应该越来越易于考虑，易于了解。也许可视化编程是大势所趋，就像机器言语必定被汇编言语替代，汇编言语必定被高档言语替代，但是现阶段的可视化编程的发展还需求更进一步。
哪些实践的事务场景更适合运用低代码渠道？
低代码的宗旨在于需求简化 + 人物兼并，经过预制件的方式，最大可能削减参与整个研发流程中的各类人物，一般经常兼并的人物有：产品兼并规划，后端兼并前端。
关于一些只读的，不触及体系状况改变的，页面/表单数量较少，组件自定义需求较低的场景，例如 trace 东西、开发类的小东西等，很适合运用低代码渠道开发。
而在事务初期，人力紧缺，事务需求并不十分复杂的情况下，低代码渠道也可承担一些中后台页面的建立，但跟着时刻的推移，定制化需求越来越多后，总归是需求回归到 ProCode 的开发模式，前期运用低代码节省的时刻后期都会在架构迁移的时候还回来。
