低代码的那些事
在当今数字化的时代，前端开发已成为构建出色用户体验的重要领域。然而，传统的前端开发过程往往需要耗费大量时间和精力，对于那些没有技术背景或时间有限的人来说，这无疑是一个巨大的挑战。然而，随着技术的不断进步，低代码开发正迅速崛起，为我们提供了一种简化开发流程的全新方法。
终端概念
终端 = 前端 + 客户端
在讲低代码之前，我们先来聊一聊终端概念，这个终端不是指敲命令行的小窗口，而是 终端 = 前端 + 客户端。乍一听，这个不是和大前端的概念类似吗？为什么又提出一个重复的名词，实际上它俩还是有很大区别的，在大前端里面，岗位是有不同区分的，比如前端开发工程师、客户端开发工程师，每个岗位的分工是不一样的，但是你可以把终端看成一个岗位。
下面是阿里巴巴终端开发工程师招聘的 JD，因为内容较长，我将他分成了三张图片，我们从上到下依次看。
第一张图片：
2024届实习生的招聘，招聘岗位为终端开发工程师
第二张图片：
这是他们对终端开发工程师的描述，大家主要看标了特殊颜色的字体就行
它包括原有的“前端工程师”和“移动端工程师” 相较过去，我们强调面向最终的用户进行交付，不局限于“前端〞、“移动端〞，这将显著拓宽工程师的职责、 能力边界。
第三张图片：
这是他们对终端开发工程师的岗位要求，可以从要求的第1、2、3项看到，这个岗位更侧重于基础技术、终端界面，而不是在于要求你会使用某某框架。
大家对终端概念有了一定了解之后，那么这个终端概念是谁提出的呢？没错，就是阿里巴巴。
阿里巴巴公众号改名史
这个公众号可能会有一些朋友之前关注过，它会发布前端和客户端相关的文章，但是之前的名字并不叫阿里巴巴终端技术。
我们来看看他的改名史：
- 2019年05月10日注册 "Alibaba FED"（FED：Front-end Developer 前端开发者）
- 2019年06月12日 "Alibaba FED" 认证 Alibaba F2E"（F2E：Front-end Engineer 前端工程师）
- 2022年07月08日 "Alibaba F2E" 帐号迁移改名"阿里巴巴终端技术"
所以是从此又多了一个终端开发工程师的岗位吗，显然不是的，终端开发工程师最终是要取代前端开发工程师和客户端开发工程师的，最终的目的是达到降本增效。
那如何让前端开发工程师和客户端开发工程师过渡成为终端开发工程师。
终端走向荧幕
在阿里 2022 年举办的第 17 届 D2 终端技术大会上，当然他们是这一届将大会名字改成了终端，其中有一篇卓越工程的主题简介如下：
在过去十年，不管是前端的工具链还是客户端的版本交付效能等都在快速演进，面向未来，我们升级工程体系走向终端工程一体化，覆盖前端及客户端工程师从研发交付到运维的全生命周期，利用低代码、极速构建、全链路运维、Serverless 等新型的工程技术，在卓越工程标准推动下引领终端工程师走向卓越。
可以看到，低代码是可以作为实践终端的一种技术方案，并且将其放在了第一位，那么什么是低代码，低代码能做什么事情，为什么使用低代码可以让终端开发工程师变的更加卓越？低代码对我们普通的一线开发又能带来什么改变或者赋能？
好，接下来，我们就来聊一聊低代码。
什么是低代码
Low-Code
低代码来源于英语翻译——Low-Code，当然，此“Low”非彼“Low”，它意指一种快速开发的方式，使用最少的代码、以最快的速度来交付应用程序。
低代码的定义是什么
虽然低代码已经是个老生常谈的话题了，但关于它的定义我觉得还是有必要描述一遍（来自ChatGPT）：
低代码是一种软件开发方法，旨在通过最小化手动编码的工作量，利用可视化工具和组件来快速构建应用程序。它提供了一个图形化的界面，使开发者能够以图形化方式设计和创建应用程序的用户界面、业务逻辑和数据模型，而无需编写大量的传统代码。
低代码它作为一种软件的开发方法，他不仅仅可以作为终端的解决方案，也可以在后端、IOT、大数据等领域上进行使用，并且这些领域也都有现成的低代码开源工具或者平台。
传统前端开发 VS 低代码开发
传统的前端开发方式，我们需要使用 HTML + CSS 描绘出页面的骨架，再使用 JAVASCRIPT 完成页面的功能逻辑。
可以看到图片上，我们定义了三个 div 元素，并且给每个 div 元素加上了背景颜色，并且加上了点击事件。每一块的元素，都需要我们使用相应的代码去描述。页面越复杂，描述的代码量就会越多。页面的代码量越多，相应的维护的成本就会越高。
我们在来看下如何使用低代码进行开发：
左侧物料区，中间画布区，右侧物料配置区，这种区域划分也是比较常见的低代码平台布局。选择物料以后，将物料拖进画布区，接下来我们就可以对物料进行属性配置。
相较于故枯燥难懂的代码，直观的拖拉拽显得更加简单，也更加容易理解。
背后的原理是什么
通过简单的托拉拽后我们可以看到一份表格页面，那么页面实际上是如何生成的呢？
背后实际对应的一份 Schema 描述，主要由物料描述和布局描述组成。
我们从左到右依次看，componentsMap 记录了我们当前页面使用的组件，可以看到我们使用了Form.Item、Input、Table，以及这些组件来自的 package 包信息。
componentsTree 里面记录了整个页面布局的信息，最外层由Page组件包裹，然后依次是 Form.Item组件，label 标签为姓名，里面还有一个 input 作为子元素，后面还有两个 Form.Item，为年龄和地址，最后的元素是 Table 组件，通过这些信息，我们就可以布局出一份简单的表格页面。
componentsMap 描述了我们当前页面所需的物料，componentsTree 描述了我们当前页面的布局顺序，将这两份数据组合，通过特定的解析器，就可以得到一份页面。低代码的页面渲染是通过我们事先约定好的数据结构进行生成的。
Schema ⇒ 页面，会不会使我的页面加载变慢
可能会有一些同学心中会有疑问，通过 Schema 生成页面，应该是需要一层 runtime 层吧，通过一段运行时的代码，将 Schema 转换为页面。
那在将 Schema 的内容转换为页面的时候，难免会产生性能上的损耗吧？
性能 VS 可维护性
这里就涉及到了性能 和 可维护性的取舍了，平台的意义在于为你掩盖底层代码的操作。让你用更直观的方式来描述你的目的，其实这里可以牵扯出另外一个相似的话题。
真实DOM VS 虚拟DOM
现代化的前端框架都会使用虚拟 DOM，那大家觉得真实DOM更快还是虚拟DOM更快？
框架的意义在于为你掩盖底层的 DOM 操作，让你用更声明式的方式来描述你的目的，从而让你的代码更容易维护。
没有任何框架可以比纯手动的优化 DOM 操作更快，因为框架的 DOM 操作层需要应对任何上层 API 可能产生的操作，它的实现必须是普适的。
针对任何一处基准，我都可以写出比任何框架更快的手动优化，但是那有什么意义呢？在构建一个实际应用的时候，你难道为每一个地方都去做手动优化吗？出于可维护性的考虑，这显然不可能。框架给你的保证是，你在不需要手动优化的情况下，我依然可以给你提供过得去的性能。
你会发现低代码的 Schema 和 虚拟 DOM 是比较相似的，都是通过对象的形式去描述 DOM 节点，
虚拟 DOM 的另外一个优势，是在于实现跨端，将底层对 DOM 操作的 API 更换为对 Android 或者 IOS 的 UI 操作。同理低代码的 Schema 也可以比较好的实现跨端，思路基本是一致的，Schema 只是一份组件 + 页面的描述，你可以根据不同的场景，进行不同平台的组件的渲染。
有没有办法可以优化页面渲染的性能吗？
那么有没有解决方案呢？
是有的，我们可以通过 Schema 的方式对页面进行出码，出码后是一套完整的应用工程，基于应用工程在去对应用进行一次构建，将这部分负担转移到编译时去完成。
生成的应用工程和我们平常开发的应用工程基本相似：
什么是低代码？
如果之前你没有听过低代码，到这里你还是没有明白低代码是什么。没关系，你可以暂时的把他理解一个可视化编辑器，通过拖拽元素就能生成页面，页面背后实际对应的是一串 Schema JSON 数据。到最后，我们会重新对低代码进行一个定义。
低代码发展趋势
低代码发展时间线
我们来看下低代码发展的时间线：
- 1980年代：出现了第四代编程语言（ABAP, Unix Shell, SQL, PL/SQL, Oracle Reports, R）第四代编程语言指的是非过程的高级规范语言，包括支持数据库管理、报告生成、数学优化、图形用户界面(GUI)开发和 web 开发。
- 2000年：出现了 VPL 语言（即 visual programming language 可视化变成语言）
- 2014年：提出了低代码 / 零代码概念
- 2016年：国内独立的低代码开发平台开始相继发布
- 2021年：中国市场逐渐形成完整的低代码、无代码生态体系
发展趋势
这是 OSS Insight 上关于低代码的一组统计数据，他们分析了50亿的 Github event数据，得出了这些报告，我从里面摘选了和低代码相关的部分。
首先，在2022年热门话题的开源存储库活跃度，LowCode 以76.3%活跃度位居第一，其次是Web3、Github Actions、Database、AI，可见大部分低代码开源仓库都处于一个开发或者维护的状态。
我们在来看下，低代码发展的趋势图，从2016年到2020年，低代码整体处于上升趋势，并且新增仓库在2020年达到最高点，新增低代码相关的仓库高达了300%以上。
在2020年野蛮生长后，2021年的新增仓库趋近于0，但是在2021低代码相关仓库的start数量将近增长了200%，2022年的数据开始趋于平缓，并且新增仓库数量减少，标志着低代码技术沉淀趋于平稳，百花齐放的时代已经过去。
没有规矩，不成方圆
百花齐放下其实是关于低代码标准的缺失，每套低代码平台都有自己的行为标准，各个平台之间的物料是有隔阂的，无法通用的。就有点像现在百花齐放的小程序，比如微信小程序、支付宝小程序、百度小程序等等，从一定程度上来讲，标准的缺失，会给用户和开发者带来了一定的困扰。
如果有行业组织或者技术社区可以积极推动低代码标准化的倡议，制定统一的行为标准和规范，标准物料的
定义，那么对于低代码的未来发展是一件非常有利的事情。
低代码产品矩阵
我们看来下国外的低代码产品矩阵，种类和平台还是非常多的。
可以看到关于低代码的落地场景其实有非常多，并且已经有了大量成熟应用流入市场，所以低代码作为一种开发软件的方法，可以将其灵活运用在各个场景。
而且每个场景的低代码，在其下还可以细分领域，比如 Web 应用程序开发，可以细分为中后台管理搭建、活动推广页面、图表大盘页面等。
一款低代码平台，通常都会有它自己的定位，是为了解决某种特定领域下的特定业务而生。所以一个公司内部有十几个低代码平台是很正常的，他们在细分下的业务场景有不同的分工。
我们正在做什么
这一章节分为三个小块来讲，为什么要做低代码、怎么去做低代码、现在做的怎么样了
为什么要做低代码
我们为什么要做低代码，低代码其实能解决的问题和场景有非常多，那么低代码能帮我们研发团队解决哪些问题？
1.由繁去简
通常一个需求下来，
- 产品会先对需求进行规划，产出一份原型图交付给 UI 设计
- UI 通过产品提供的原型图，对原型进行美化，产出一份设计稿
- 前端对照设计稿进行页面开发，交付高保真的页面
- 最后进行接口联调，将静态的数据更改为接口获取的数据
做程序本质上也是在做交流，假设我们现在是一位前端或者客户端的开发工程师，
- 我们需要先和产品 battle 原型图
- 和 UI 讨论设计稿
- 交付高保真的页面
- 和后端进行接口联调
可以看到绝大部分的时间都花在了如何去做页面上，在加上关于各个环节对页面的讨论和修改，这中间会产生大量的浸没成本。
如果说，现在有一个工具，可以做到产品交付的就是高保真页面，你会选择用还是不用？
这个是使用低代码后的开发流程，由产品直接生成高保真页面交付给前端，极大提高了开发生产力。那么，这个时候前端可以更加聚焦于业务逻辑，聚焦于工程体系，而不是页面本身。
2. 我不想在去改样式了
好像所有的产品经理都喜欢在项目即将上线前，对页面的样式进行调整，没错，既不是测试阶段，也不是预发阶段，而是即将发布前，改完一个，在改一个，好像总是也改不完。
而使用低代码平台后，将页面生成的权利递到产品经理手中，他们可以随心所欲的修改，尽情的展示自己的创造力，我们也不在需要反复的修改样式，反复的重新构建应用发布，你可以专心的去做其它事情。
3. 真正的所见即所得
真正的所见即所得，相比于黑盒子的代码，低代码平台显得更加直观，操作的是页面，而不是代码，你可以在平台上尽情的组装，就像是搭积木一样。
怎么去做低代码
在能够协调足够多的资源的情况下，选择自研是比较好的一条路，因为一切都是可控的。
但是在资源有限的情况下，选择开源或许是一种最快最便捷的方法了。我们在低代码发展趋势中，可以发现低代码平台和开源技术已经趋于稳定。
使用稳定的开源框架可以更快的帮助我们创建低代码平台，并且有足够多懂低代码底层的人，去帮助我们维护基础设施，站在巨人的肩膀上出发，往往会事半功倍。
我们选择的是阿里开源的 lowcode-engine，在其基础上进行二次开发，选择它的理由有很多：
现在做的怎么样了
下面是平台的真实演示，目前已经支持开发以及发布预览了。
低代码架构图：
平台使用流程的步骤图：
- 第一步是创建应用
- 第二步是创建页面，当然一个应用下面可能会有多个页面，每个页面都会是相互独立的，
- 第三步是布局调整，可以在选中的页面进行拖拽物料进行布局
- 第四步是属性配置，配置物料的属性，配置物料的事件或者样式，提供自定义样式和逻辑的功能支持
- 第五步是保存发布，将当前各个页面的schema进行保存上传，存储到数据库
- 第六步是页面渲染，可以直接通过平台生成的页面地址，打开页面
被误解的低代码
我相信是会有一大部分的程序员从内心抵制低代码的，一方面，作为一个技术工种，对自己的技术是有底气的，有傲骨的，人为写的代码都不怎么样，还指望低代码平台上的代码吗，另一方面，在低代码平台的代码上维护，那简直就是在屎山上维护，维护的成本会更大吧
出码 VS 不出码
这里的痛点是在于需不需要维护低代码产出的代码，前面我们讲到过出码，出码可以用于产物构建。但构建这一块，是平台去做的，用户并不会感知到背后实际的应用工程。
出码同时也可以用于用户的自定义需求，如果平台的物料完全覆盖了你的业务场景，你是不需要去出码的。但是，如果平台的物料无法满足你的业务场景，你需要的组件又具备足够的特殊性，这个时候你可能需要使用出码功能，在出码的应用工程基础下，添加自己的业务代码，那么这个时候，你是需要维护整个应用工程的。
对低代码的分歧往往是这个时候产生的，每个人心中都有自己的标准代码，都会本能的去抵触和自己标准不同的代码。
不出码如何自定义开发需求？
那有没有既不出码，又可以满足自定义开发的需求呢？
因为我们更多的是希望平台去维护工程，而不是通过人为方式去维护。像我们平时开发页面，本质上就是在写组件，通过拼装组件，形成页面。
我们的思想上可以做个转变，既然 80%~90% 的工作平台可以承接，剩余的平台无法实现，可以自己实现自定义组件进行发布，发布的组件可以沉淀到市场，你的其它项目可以使用自己的业务组件，其他同事也可以使用你的组件。
低代码会不会导致前端岗位变少？
其实完全可以将低代码看成提升工作效率的一个工具，低代码解决页面视图，页面逻辑和数据联调需要开发者在平台上进行完成，开发者的关注点更多的聚焦于业务逻辑，聚焦于如何去做好工程化体系。
AI Code 不是更好吗？
那好像 AI Code 也可以做到低代码能做的地步？
在今年3月份 GPT-4 的发布会上，只需要在草稿本上用纸笔画出一个非常粗糙的草图，再拍照告诉GPT-4需要一个这样的网站，AI 就可以在10秒钟左右根据草图，生成一个网站完整的前端 HTML 代码。
这简直就是低代码 plus，回归我第一次使用 GPT 的时候，我确实是被惊讶到，特别是他能衔接上下文关系，给出你想要的答案。
我们开发应用，其实本身就是一个庞大的上下文，版本一直迭代，需求一直新增，通过人本身去记住业务上下文，在一个足够复杂的应用下，他的上下文会足够大，足够的冗余，我们去抽离组件，抽离函数，使用数据结构优化代码，实际上就是在优化上下文，写代码并不难，难的是如何梳理页面的组件和那些难以理解的业务以及那些人与人的沟通。
至少现在看来，GPT 无法做到承接复杂应用的上下文，现在的他只能帮助你快速产出一个 demo 应用，前提你需要做到甄别代码的能力，以及还需要面临后续版本迭代更新的窘境问题。
或者说，如果 AI 真的能做到独立开发复杂应用，程序员就真的会被取代吗，做程序本身就是一个相对复杂的活，需要持续学习，持续精进。如果AI真的能做到独立开发这一步，那我觉得离真正的无人驾驶也不远了，出租车司机全部都得失业，因为做一个程序相比于驾驶车辆，会难上不少，当然还包括其它行业，80% 以上的职业都极有可能面临下岗危机。
这个是政客、政府不允许的，虽然科技进步是好事，但是 AI 并没有带来实际的增量工作岗位，反而导致失业率变高，失业率若变高，整体社会的稳定性结构就会变差。
所以，我们更多的将 AI 看成工具，关注点在于，如何用 AI 去做成更多的事情。
什么是低代码？
讲到这里，基本上今天的分享就已经进入尾声了，最后我们在来确定下什么是低代码？
低代码是一种
软件开发方法，旨在通过最小化手动编码的工作量，利用可视化工具和组件来快速构建应用程序。它提供了一个图形化的界面，使开发者能够以图形化方式设计和创建应用程序的用户界面、业务逻辑和数据模型，而无需编写大量的传统代码。
一千个人眼中，有一千个哈姆雷特，每个人对低代码的理解都会有些许不同，首先低代码是一种软件开发的方法，这套方法可以用在很多场景。如果一个平台提供了可视化的工具和组件并且又提供部分手动编码的能力，它就可以是一个低代码平台。
在前端低代码的方案中，并不是不再使用 HTML、CSS、JAVASCRIPT 进行开发，而是大大减少他们的使用频率，通过少量的代码，就可以完成一个页面的开发。
