内容纲要 >>>
• 行业背景
• 业务背景
• 实践方案
• 混合开发
• 未来展望
——————————————————————————————————
NO.1
行业背景
近年来低代码领域的讨论热度不减，企业开始关注如何使用低代码技术和思想来提高研发产出效率。目前业界开源、开放的方案大多是适用于通用场景的。而实际上每个企业的业务都是独具特色的，如何让低代码技术能适用于自身独具特色的业务，这才是更多企业关注的方向。
在趣丸科技，团队的业务不同于类似表单流程这种通用的、有业界标准场景。业务场景并非通用，而且多变。不同于ToB业务，而趣丸科技技术团队的业务是ToC的，需要有华丽的UI和充满个性的风格。基于以上特点，我们的挑战在于：如何在业务中抽象通用逻辑？如何提供足够自由的diy能力？
为此趣丸科技开发了 “白鲸” 低代码平台，它不同于通用的低代码解决方案，而是为公司的业务量身打造的。需求方可以绕过研发人员，直接通过配置、拖拽的形式上线Web页面。不仅大幅提升了此类需求的交付效率，也让之前重复的逻辑和元素以模板、组件的形式得到不断的迭代和沉淀。
NO.2
业务背景
趣丸科技业务产品的运营活动业务需求量大，平均每个季度有超过60个运营活动的需求。
先绍一下什么是运营活动，方便后续的理解。运营活动其实就是：趣丸科技直播业务的一种提高用户活跃度的手段。
上图就是运营活动页面，有点眼花缭乱，我们把它抽象一下。
以上就是一个经典的运营活动由三部分组成：最上面的活动海报（也就是一张图片）、中间的任务模块、最后的抽奖模块。
用户通过完成平台特定的任务获得抽奖机会，再通过最下面的轮盘抽奖模块进行抽奖。
NO.3
实践方案
1、分析
回到刚刚这个运营活动案例，我们把这个案例分解为四个组成部分，如下图：
这些部分称为组件，也就是页面组件、图片组件、任务组件、抽奖组件。但因为这个案例在布局上相对简单，所以为了应对更加复杂的需求，我们通常会需要布局相关的组件，比如：格栅和tab布局，也就是大概需要以下这些组件，就可以组装成一个完整的运营活动。
2、方案
基于以上的分析，技术团队构思了这样一个方案，首先需要一个页面的设计台，如下：
左侧是活动项目的组件，中间是预览设计页面。需求方，也就是项目组的运营人员，将通过拖拽的形式将组件按需进行拖拽到中间的预览设计区进行组装。而每个组件的自定义配置则在右侧的组件配置项区进行配置，比如抽奖轮盘组件需要自定义奖品的名称中奖概率、轮盘的背景等等，如下图所示：
3、技术实现
在整个方案中，组件是最核心的，我们的组件需要部署到云端、提交到配置项。部署到云端是给设计台动态加载用的，而提交配置项是给设计台渲染配置项对应表单使用的。它们的关系如下：
那么一个组件从代码提交到部署到提取并保存配置项的过程大致如下：
如上所示，代码提交到代码仓库（Gitlab）后，会执行两个 CI/CD 任务。
一个是构建成 webpack 联邦模块，并部署到 cdn。这个联邦模块是 webpack 原生支持的一个简单的微前端能力。
另一个任务是提取组件的配置项，并提交到设计台的服务端。
关于第一个任务webpack的联邦模块，方法比较简单，官方文档也比较详细，这里就不展开说明。因此我们着重讲一下第二个任务，也就是提取组件配置项的任务。
首先，我们先来回顾一下组件配置项，以抽奖组件为例，组件的配置项有奖品的信息，还有轮盘的样式等等：
为了让组件适用于各种业务逻辑，灵活度更高，通常我们的组件配置项的配置项会比较多，比如一个组件会有几十个配置项。配置项在整个系统中扮演着贯穿始终的重要角色，具体如下图：
可以看到，在组件代码中定义了配置项，并通过脚本提取出代码中的配置项，提交给设计台的服务端，设计台再根据配置项数据渲染出对应表单，用户填写表单便生成了配置项数据，配置项数据在组件运行时或者预览时会传递给组件。我们来看一下配置项在代码中的定义：
这里要说明的是，我们的系统是基于 vue 的，组件也是用 vue 写的。我们都知道 vue 是通过定义 props 来传递数据给组件的。因此我们沿用了这种风格，将组件的配置项定义在 props 中，这样既方便后续数据传递给组件，也符合 vue 的使用习惯。
我们在 props 上拓展了一个自定义的字段，通过这个字段来区分是我们的配置项还是普通的 props，并且通过这个字段累定义配置项的一些信息，比如：这个配置项用什么表单，是普通输入框，还是下拉框，还是多选框等等，这些信息用于设计台渲染配置项表单的时候使用。接下来我们要做的是把这些配置项从代码中提取出来。
上面是一个完整的vue单文件，其中包括模板，脚本，样式。我们的做法也很简单，先通过正则，把中间脚本部分提取出来，然后在运行这部分的脚本，就可以获得组件的props，如下图：
当然实际情况会比这个复杂一些，我们还需要处理像子组件配置项问题，这时候我们会用AST技术去识别和修改脚本的语法。
成功获取到组件的配置项后，接下来我们把这些信息交给设计台，设计台渲染出表单，用户填写表单，我们就获取到了配置项的数据，这时候再将数据回传给预览区域的组件，如下图：
当然这些配置项数据也会保存到我们的设计台服务端，用于我们运营活动部署的时传递给组件。接下来就讲一下部署的流程。
用户在我们的设计台拖拽了所需的组件以及填写了组件的配置项，点击发布，这时候我们就会执行部署的任务。部署任务会根据用户拖拽的组件，来拉取对应的组件代码，再根据拖拽的顺序和嵌套关系，生成类似这样的代码：
这个步骤其实就是将用户拖拽设计出来的产物转化为对应的代码，接着我们就可以运行构建命令，进行构建和部署。另外还有一点，就是我们的业务组件都有对应的服务端docker镜像，在部署的时候我们也会调用k8s的能力把对应组件的服务端镜像进行部署，并且将配置项中一些服务端需要的数据通过环境变量的形式传递给后端服务。
NO.4
混合开发
在实际使用中，我们发现，很多时候会出现以下两种情况。
情况一：80%的功能可以通过我们的低代码的组件组合实现，但20%是无法实现。就像这样：
情况二：也可能反过来20%的功能可以通过我们的低代码的组件组合实现，但80%是无法实现。就像这样：
以上两种情况下，只能是整个需求都只能是回到我们常规的手动写代码的方式来做，也就是proCode。这显然是很低效的方式。针对以上的情况二，我们开发了混合模式，也就是在proCode主导的页面中嵌入了lowCode的产物：
实现的方式其实就是微前端技术，通过动态远程加载的方式嵌入低代码平台的产物。后续我们还将将针对情况一实现在 lowCode 主导的页面中嵌入 proCode 的产物。
NO.5
未来展望
展望未来，低代码技术将成为应用程序开发的主流方法之一。同时，随着技术的不断进步和开发人员对低代码技术的提高，功能将不断扩展，从而更加灵活和强大。
近期chatGPT4的发布会演示了10秒生成页面让人印象深刻，AI+低代码也是未来一个值得探索和期待的方向。
期待AIGC技术为低代码这个领域注入更多的 “ 新鲜血液 ”，为网页和程序开发带来持续高效、智能和创新的可能性。后续白鲸低代码平台也将在 “ 一句话生成页面 ” 的基础上进行更深入的发展，提升交互和视觉效果，优化平台用户体验，让用户能够更轻松地创造自己想要的网页和程序。
