规模化的组织，经常要⾯临这样的挑战：每个应⽤的基础设施是相同的，部分的代码也是相同的，甚⾄于它们可能只是数据模型不同⽽已。结果却导致了，他/她们要⼀次⼜⼀次地重新编写⼀个应⽤。对于⼀个新的应⽤⽽⾔，它需要对接⼤量的三⽅（⾮⾃⼰团队）服务。服务之间的不断变化 ，导致了对应的使⽤⽅也需要发⽣变化。不断变化的业务，导致了前台的设计不断变化。为了应对快速谈的的前台服务，后台便诞⽣了中台，以提供快速的响应能⼒。⽽随着中台进⼀步沉淀，从某种形式上趋于稳定，⽽前台仍然需要快速地响应能⼒。
于是乎，作为⼀个前端开发⼈员，我们不断提炼和复⽤代码，想着的模式在之前的⽂章已提到了：
脚⼿架
组件库
模式库
模板和模板应⽤
对应的，我们还创建了⼀系列的 CLI、⼯具集、编程器插件以及设计系统，以完成整个系统的快速开发。然⽽，我们还缺少⼀套有效的⼯具，来统⼀化的管理这些⼯具。
换句话来说，就是：我们需要⼀个前端的中台，它便是⽆代码/低代码编程。
01 什么是⽆代码编程？
⽆代码/低代码是⼀种创建应⽤的⽅法，它可以让开发⼈员使⽤最少的编码知识，来快速开发应⽤程序。它可以在图形界⾯中，使⽤可视化建模的⽅式，来组装和配置应⽤程序。开发⼈员可以直接跳过所有的基础架构，只关注于使⽤代码来实现业务逻辑。
当然，从开发⼈员的⾓度来看，降低代码量，可能是：
框架本⾝处理了复杂性。毕竟 “复杂度同⼒⼀样不会消失，也不会凭空产⽣，它总是从⼀
1. 框架本⾝处理了复杂性。
个物体转移到另⼀个物体或⼀种形式转为另⼀种形式。”
代码⽣成减少了⼯作量。⼤量的复制、粘贴需要更多的时间。
1. 代码⽣成减少了⼯作量
流程
只是凭借这个概念，我们是⽆法理解⽆代码编程的。于是，我画了⼀张图来展⽰相应的架构和流程：
低代码编程流
依照我的观点来看，我将⽆代码编程分为了两部分：
⽤于构建 UI 的编辑器——⼀种在线的拖拽式 UI 设计和页⾯构建⼯具
⽤于编写业务逻辑的流编辑器——通过流编程的⽅式来编写业务代码（多数是对于数据的处理）
UI 编程器
为了设计出我们的 UI 构建器，我们需要准备好⼀系列的基础设施：
UI 编程器。⽤于拖拽式设计 UI。
空⽩脚⼿架。⼀个带有完整的应⽤⽣命周期的项⽬，但是它是⼀个空⽩的项⽬——⽤于我们在构建 UI 的过程中，随时随地的添加组件和代码。
设计系统。我们需要⼀个完整的组件库，⼤量的页⾯模板，以及⼀定数量的模板应⽤，减少相应的开发⼯具量。
代码⽚段集。它将设计系统中的组件库进⼀步实例化成代码段，在完成编辑后通过 CLI 来动态编辑代
码。
中元节的禁忌有哪些DSL（领域特定语⾔，可选）。中间⽣成物，⽤于隔离框架与设计。
流编程器
流编程器。⽤于拖拽式、输⼊编写业务代码。
后端服务。如果不能提供现成的后端服务，则需要拥有⼀个标准的 API 规范，以及相应的 mock server。
模式库。包含相应的业务处理代码，如通⽤的登录、数据获取、UI 交互等。
DSL（领域特定语⾔，可选）。同上
理科女生学什么专业当然了，我们还需要能实时预览构建出来的应⽤。随后，我们执⾏了构建，⽽后构建出了⼀个半成品应⽤。开发⼈员只需要在它的基础上开发应⽤即可。⽽在开发⼈员开发的过程中，我们可以设计⼀系列的⼯具，来帮助开发⼈员更快速地构建应⽤。
编辑器插件。包含设计系统、模式库等的⾃动完成代码，以及组织内部常⽤的代码库。
调试⼯具。对于混合类型的应⽤⽽⾔，我们还需要⼀个开发⼯具来快速构建应⽤。
特点：
从上述的流程上来看，⽆代码编程还具有以下的特点
拖放式界⾯。⼜或者是可视化模型——基于节点和箭头。
拖放式界⾯
基于视觉的设计。
基于视觉的设计
可扩展的设计。如对于插件、插件商店，社区等⼀系列的⽀持。
可扩展的设计
跨平台功能。⽀持 PC Web 应⽤开发，⽀持移动应⽤构架等。
跨平台功能
强⼤的部署后
强⼤的部署后。即平台包含着整个应⽤的⽣命周期。
拥有丰富的集成⽀持。可以随意的到需要的组件，以及对应的后台服务。
拥有丰富的集成⽀持
配置化。它也意味着⼤量的⾃定义配置。
配置化
⾃制的领域特定语⾔（可选）。⽤于构建时优化。
⾃制的领域特定语⾔
优缺点
相应的，它具有以下的⼀些优点：
1. ⾼效。不⽤多说，节省时间和开发成本。
2. 有限的 Bug，安全性。
3. 低成本。其所需的预算⾮常有限。
4. 易⽤（取决于设计）。
5. 开发速度更快。
6. 开发过程中的 AI 。
7. 维护成本低。
对应的相应的缺点有：
1. 仍然需要编程技能。
2. 受限的⾃定义能⼒。
3. 可扩展性成了新的问题。
4. 集成受限。
就当前⽽⾔，低代码开发平台通常分为两⼤类：
对于外部：制作简单的产品，如⽹络移动应⽤程序
对于内部：为您的团队或企业创建业务应⽤程序
CRUD、表单、验证、简单聚合、分页等简易的服务。最常见的例⼦就是表单构建了，诸如⾦数据这样的应⽤，便是可以直诸如只使⽤ CRUD、表单、验证、简单聚合、分页等简易
接通过拖拽元素来⽣成，相应的开源实现有 jQuery Form Builder。
对于开发⼈员来说，我们只需要定义好数据模型，再通过拖拽来决定元素的位置即可。从这种⾓度来看，只要能使⽤ Serverless 构建的应⽤和服务，都可以直接使⽤低代码开发模式。
欢迎⼯作⼀到五年的Java⼯程师朋友们加⼊Java开发：828697593
本提供免费的学习指导 架构资料 以及免费的解答
同时⼤家可以多多关注⼀下⼩编 纯⼲货 ⼤家⼀起学习进步
02 开发流程对⽐
从我们的理解来看，传统应⽤的开发流程是：
1. 分析、设计、确认、规划需求。
2. 设计系统架构。
3. 搭建前后端项⽬。选择技术栈、从零开始搭建或者从脚⼿架中创建。
4. 搭建持续集成。
5. 创建线框图和⾼保真原型。
6. 设计数据模型，定义前后端契约，即 API URI、⽅法、字段等。
7. 前后端实现业务逻辑。
8. 前端实现 UI 页⾯。
9. 集成第三⽅后端服务。
10. 功能需求测试（DEV、QA、ST、UAT）
11. 跨功能需求测试（安全性、性能等）
12. 部署到⽣产环境。
低代码开发流程：
1. 分析、设计、确认、规划需求
2. 选择需要的第三⽅ API
3. 在可视 IDE 中绘制应⽤程序的⼯作流程、数据模型和⽤户界⾯。
4. 连接 API——通常使⽤服务、函数发现。美国电话号码
5. 编写业务逻辑（可选）。⼿动代码添加到前端或者⾃定义⾃动⽣成的 SQL 查询。
6. ⽤户验收测试。
7. 部署到⽣产环境。
从步骤上来看，⽆代码编程少了⼏个步骤。这些步骤都因为⼤量丰富的内部系统集成，⽽变得⾮常简单。
03 适⽤场景
就当前⽽⾔，⽆代码编程实际上是⼀种⾼度的场景预设的模式。因此，它存在⼀定的适⽤场景：
模型驱动开发。
快速 UI 构建。
极简的业务功能。
IT 资源受限。在资源受限的情况下，能快速开发出符合业务需求的应⽤最重要。
⽽从流程上来看，对于⼀部分的应⽤来说，我们并不能实现⽆代码编程——存在⼀些业务上的不同之处。因此，多数场景之下，只是实现
多数场景之下，只是实现了低代码编程。
若是想真实的⽆代码编程，则需要⼀些更特定的场景：
设计表格（输⼊数据）
创建报告（组织数据）
常规调度和⾃动化过程（操纵数据）
更多的场景正在探索中。节日问候
04 ⽆代码编程的挑战
⽆代码编程，除了需要准备好上述的⼀系列基础设施，还不可避免地会遇到⼀系列挑战。
1. 谁来写这部分代码？
2. 客户端的基础设施准备。
3. 服务端的服务平台搭建。
4. 统⼀⽤户体验设计。设计出⼀系列能便利组合的组件，及对应的模板页⾯。与此同时，它们还能适应于不同的风格，即有多样性的主
题⽀持。
5. DevOps 流⽔线设计。低代码编程，依赖于⼀系列的⾃动化⼯具，以实现构建、调试、部署以及维护，同时还包含应⽤的测试。
6. 领域语⾔设计。
7. ⾃动化测试。如果我们的前端代码是⾃动⽣成的，那么我们还需要对它们进⾏测试吗？这是⼀个好问题，⽽如果代码是⾃动⽣成的，
那么测试也应该是⾃动⽣成的。毕竟要在平台上，编写⼤量的⾃动化测试，以保证平台的质量。
其中，有⼀些部分略微复杂⼀些，我们⼤概可以探索⼀下。
05 谁来写这部分代码？
在我们创建这样⼀个平台和⼯具时，我们要考虑的第⼀个问题是，这个⼯具是为谁写的？
没有编程经验的⼈。如业务⼈员，他/她们对于业务系统有着⾮常丰富的经验。
有编程知识，但是没有经验的⼈。
有⼀定经验的开发⼈员。
有丰富经验的开发⼈员。对于专业的⼈来说，⾃动化就意味着缺少灵活度。甚⾄与⾃⼰编写相⽐，他们要花费更多的时间来修复⽣成的代码。
显然，对于相当有经验的开发⼈员⽽⾔，这个⼯具并不⼀定是他们所需要的。
06 客户端基础设施
从我的理解来看，它适合于快速的 MVP 构建，并且⽣成的代码还应该⽅便修改，⽽不是诸如早期的 DreamWeaver 或者 FrontPage 这样的⼯具。
⽽与此同时，由于⾯向的开发⼈员⽔平不同，我们所需要做的⼯具也不同：
1. ⽀持云构建和调试。
2. GUI 编程应⽤。
3. 代码⽣成。
4. 设计系统体系构建。组件库搭建，模板应⽤创建等。
更难的是，容易让开发⼈员能接受代码⽣成。
感兴趣的来Java架构，可以获取免费的学习资料，828697593 对Java技术，架构技术感兴趣的同学，欢迎加，⼀起学习，相互讨论。
07 服务端
对于⼀个低代码平台⽽⾔，它对应的后端应该：
1. ⼤量可⽤的现有服务。⾝份验证、安全性、推送能⼒、地图等等。
2. 快速构建出后端服务。若是有内部 Serverless 或者 FaaS ⽅案，可以说是再好不过了。
3. ⽅便与第三⽅服务集成。
4. 灵活性。⽀持多语⾔等。
统⼀的后端服务 API，对于后端服务来说，我们需要⼀个通⽤的范式。所有的 API 应该按照这样的范式来设计。不过，作为⼀个 API 的消费⽅，我们可能没有这么⼤的权⼒，但是我们可以采⽤装饰器模式，即封装第三⽅ API 成统⼀的⽅式。为此，我们采⽤的⽅式，仍然是：
契约。诸如 Swagger UI，它可以直接创建⼀个简易可⽤的服务。
BFF。即我们⼀⼀去按我们的需要，去封装这些第三⽅应⽤。
查询语⾔。与⾃⼰编写 BFF 相⽐，更简单的⽅式是采⽤：GraphQL 这样的后端查询语⾔，便捷性更
⾼、模式更加灵活。
在开发前的设计期⾥，我们需要⾸先设计出对应的领域模型。
08 领域语⾔设计
低代码环境使⽤（图形）建模语⾔来指定整个系统、产品的⾏为。它意味着：
1. 将数据结构、领域模式应⽤到程序的各个层级中。
2. 将业务规则、决策融⼊到应⽤中（层级）。
这也就意味着，我们需要设计⼀个模型语⾔。⽽它对于我们⽽⾔，实际上是领域特定语⾔（DSL）。如下是⼀个简单的 DSL ⽰例，⽤于描述使⽤到的组件：
全国高速免费最新消息{'style': '','id': 2,'blocks':
[{'content': {'content': 'content','title': 'hello'},'type':'card'}]
}
非常完美赵威霖除此，我们还需要设计对应的布局 DSL，诸如于：
H:[circle1(circle1.height)] // set aspect-ratio for circle1
HV:[circle2..5(circle1)] // use same width/height for other circles
H:|[circle1]-[circle2]-[circle3]-[circle4]-[circle5]|
V:|~[circle1..5]~| // center all circles vertically
最后，我们还需要将流代码，转换为真实的项⽬代码。三种类型的 DSL 结合下来，都不是⼀个轻松的⼯具。
09 原型设计
写好现有的组件，通⽤型接⼝。如常见的登录接⼝，对于使⽤登录接⼝的业务来说，它们只关⼼三部分的内容：
1. 成功登录。
2. 取消登录。
3. 登录失败。对于客户端⽽⾔，可以视为取消登录。对于服务端来说，则可能是密码错误、⽤户名不
存在、账号被锁定等。
发布评论