前言
本文是笔者在团队内部做分享整理的资料的一部分，本次分享主要是站在一个服务端开发的视角对（前端）低代码平台的一些调研，已经剔除了一些敏感数据和信息，可放心食用。
太阳底下无新事
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）
考虑到数据安全，这一部分在原文基础上做了较多改动，基于集团已经开源的信息做介绍，详情可跳转至官网地址 👉 https://lowcode-engine.cn
低代码平台的底层是低代码引擎，引擎核心在于灵活对接丰富的高质量物料，结合一个优雅、高效的编排引擎，让一个泛技术线的同学用所见即所得的方式，完成页面的搭建、部署，完成快速自交付的闭环，达成预期目标。
其中引擎 SDK，包含 4 个主要模块，即入料、编排、渲染、出码。
- 入料：将物料，按照《低代码引擎物料协议规范》进行元数据描述后，导入到设计器中，成为一个可被编排的物料；
- 编排：将设计器中的所有物料，进行布局设置、组件设置(CRUD)、交互设置(JS 编写/逻辑编排)后，形成符合业务诉求的 schema 描述，此 schema 遵循 《低代码引擎搭建协议规范》；
- 渲染：将编排得到的 schema 渲染成可交互的页面；
- 出码：将编排得到的 schema 转成真实的代码结构，比如 Recore / Ice / Remax / Umi 等应用框架结构；
体验低代码开发后的感受
黑盒开发
因为屏蔽了一些代码，接手的人不知道为什么这个组件在这里，为什么会有这样的效果。心路历程基本如下 👇
😄 我写了一段代码，只有我和编译器/解释器看得懂。🤔 过了一段时间，就只有编译器/解释器看得懂了。
😈 我用低代码平台拖了一些"控件"，最后我发现只有浏览器看得懂。
学习成本并不低
- 需要有一定的前端知识（话说现在会 React 这类框架基本已经是必备要求了吧）然而问题是，有这些能力的基本上也可以开发一个简单的页面了
- 文档不够详细，经常需要提 issue 或者问人
- 第三方组件与生态并不完善
迭代效率提升不明显
虽然在画页面、适配样式等方面，低代码平台有非常大的优势，但由于学习成本、黑盒开发等原因，导致在开发时问题的排查效率低下，开发的幸福感大打折扣。
如果官方提供的组件库不满足业务需要时，开发自定义组件/使用第三方组件的成本和手动编写代码相差无几。
对低代码平台的一些思考
服务端编写前端代码的痛点是什么？
- 前端技术栈多&杂，不知道学习哪一个
- 重复性多做较多，布局难适配，css 编写头疼
上面两个问题，低代码平台可以解决，但是现有的前端技术也可以解决
可视化编程的效率一定比写代码效率高？
编程本质上是一种表达，它的工具应该越来越易于思考，易于理解。也许可视化编程是大势所趋，就像机器语言必然被汇编语言取代，汇编语言必然被高级语言取代，但是现阶段的可视化编程的发展还需要更进一步。
哪些实际的业务场景更适合使用低代码平台？
低代码的主旨在于需求简化 + 角色合并，通过预制件的形式，最大可能减少参与整个研发流程中的各类角色，一般经常合并的角色有：产品合并设计，后端合并前端。
对于一些只读的，不涉及系统状态变化的，页面/表单数量较少，组件自定义需求较低的场景，例如 trace 工具、开发类的小工具等，很适合使用低代码平台开发。
而在业务初期，人力紧缺，业务需求并不十分复杂的情况下，低代码平台也可承担一些中后台页面的搭建，但随着时间的推移，定制化需求越来越多后，总归是需要回归到 ProCode 的开发模式，前期使用低代码节省的时间后期都会在架构迁移的时候还回来。
