🙋🏻♀️ 编者按:本文作者是蚂蚁集团前端工程师度城,分享了在蚂蚁保险场景下,进行低代码探索的经验和思考。
2021 年 10 月份,我开始了在蚂蚁保险场景下的低码建设之路,一晃眼满满的一年过去了,不管结果如何,从 0 到 1 的产品建设过程,也收获了很多的经历和想法,通过这篇文章做一个总结,也算对自己这些年建设低码研发方向的踩过的坑做一些记录,同时给其他同学后续如果要做一些基础的技术项目做一些参考。
从上面的介绍中说到,这次来蚂蚁瞄准建设的也是 C 端场景,我之前在 1688 主要做的是导购场景,所谓导购场景,就是电商最常用的商品列表,看了下面的图大家就知道了电商场景每隔一段时间需要进行大促,为了让用户可以保持新鲜感,设计经常会对会场的主题,卡片的样式做一些变化,这样就导致每次大促都需要重新开发商品的 offer 卡片,对接数据也会有一些区别,所以通过低码我们抽象了一些容器组件,例如楼层,tab 组件,通过低码编辑器进行商品 offer 卡片的拖拽和开发,大幅提升了每次大促的活动页开发速度,同时会场列表通常逻辑也比较简单,我们通过该方法再大促中大量复制,成果显著。
刚来到蚂蚁的时候,我希望可以直接把在 1688 导购场景的经验复制过来,我简单看了下商业险最典型的几个投保场景,好像也挺简单,几个头图组件+一些交互的表单+产品图片列表,表单组件抽几个典型物料,基本就搞定了,so easy 😄。但是,当我深入去看了一下上面的代码以后,顿时心凉了半截,整个页面的结构看似简单,但是组件和组件之间需要进行联动,并不是单纯的像导购页面组建累积起来就行,同时每个投保页的逻辑异常复杂,光一个通用的投保逻辑就有上千行的代码,这还不包括一些产品的特殊逻辑等
从上面分析可以看到,保险投保场景,比导购场景复杂的多,如果直接套用原来的定位和方案,明显是不适合的,低码场景在这些逻辑复杂的场景中是否还适用?摆在我面前有两条路
其实从投入 ROI 来看,似乎第一条路更容易达成结果,简单的复制一下之前的经验,搭建一下平台,就可以完整覆盖低复杂的场景,从而更好更快的拿到结果。但是再深入分析,我们发现第一条路也不好走,原因如下
非营销场景商业险业务
复杂度 | 高复杂度 | 中复杂度 | 低复杂度 |
---|---|---|---|
车险 | 52 | 2 | 1 |
电商险 | 10 | 12 | 14 |
意财险 | 10 | 9 | 18 |
寿险 | 8 | 13 | 8 |
健康险 | 41 | 34 | 8 |
占比 | 121 (54.5%) | 70 (31.5%) | 31 (13.9%) |
商业险营销场景
营销组件基本都是低复杂组件,我们可以完整覆盖,但是由于保险业务的原因,运营主要采用图文为主进行活动页承接页搭建,新增组件量并不大。
结论:如果只专注做低复杂的场景,基本就固定了平台的上限和规模,业务的量摆在那里。同时由于平台定位低复杂场景,不具备中高复杂场景的可持续迭代能力,造成了开发者对后续迭代的顾虑和不信任,后续可预见推广举步维艰。
所以基于上述思考,我们平台定位必须具备高复杂场景的可维护能力,这样才能保证开发者在上面开发以后,不用担心后续因为业务迭代变复杂以后因为平台能力的问题导致无法迭代,提升开发者的信心。
我们仔细想一下,现有的前端技术框架是如何解决高复杂度下的维护问题的。大家现在都在使用 React,es6 的语法,但是如果大家接触前端年代更加久远的话,可以知道 Jquery、无模块概念是如何编写逻辑的,所以经过这么长时间的发展,不管前端框架、技术如何变动,我们对其中两点能力基本达成共识:
基于上述两点,我们在低码整体设计的候将这两点进行重点思考,分别通过物料系统和多文件优化对上述两点进行体现和实践。
问题: 虽然通过物料模式可以实现Procode中组件的使用,但是物料的开发还是太麻烦了,需要在线下新增一个仓库,需要通过特殊的配置和打包构建方式才可以在低码编辑器中使用。为了能进一步降低开发者的门槛,提升开发者开发物料的效率,我们在原有物料开发体系的基础上,新增在线物料研发方案,将物料的研、配置、发布和轻研发 needle 进行完整串联,改变之前组件开发线下、低码使用线上的割裂方式,通过全线上的方式提升研发的体验
通过上述两个改动,让我们的平台提升了对复杂应用的支持能力,能够在组件和逻辑两个维度进行拆解,有效的降低复杂页面的接入难度。
在设计了上述能力后,虽然在功能上可以具备复杂应用的接入能力,但是是否在实际的研发中真正有效,还需要实践进行说话,我们挑选了寿险的两个新的投保场景(储蓄型两全、学平险)作为试验,这两个是全新的投保类目,在使用低码接入的时候不用顾虑旧的改造影响,虽然新的改造必定会在后续的维护中和其他投保不一致,带来额外的成本,但是我们思考的是只有我们在自己在实际的场景中进行深度的使用,才有一手的经验去进行改进,所以即使是在后续维护中带来一定的两套维护成本,我们也需要去进行尝试。
虽然学平险由于最终业务问题没有能够正式上线,但是储蓄型两全如期上线,成为第一个通过布偶开发的投保页面,并且维护了将近半年之久(后续开放统一迁移长江),在整个开发过程中,我们认为平台的深度可维护能力是可以支撑复杂的页面级应用的,核心的部分还是在投保的逻辑编写和维护上,主逻辑将近 1700 行,对于一个低码页面来说可以说是比较重度了,我们在实操过程中也发现了不少问题
export default function xxxPlugin(ctx) {
return {
xxxx: 123,
xxxxMethod: () => {
// 获取组将状态
const state = ctx.getState();
// 更新组件状态
ctx.setState({name: 'pluginA'});
// 调用其它插件
ctx.call('pluginB.xxx');
}
}
}
如上面的例子,可以将逻辑拆成一系列插件,插件内可以通过 ctx 实例操纵组件状态,控制页面渲染,每个插件负责一块逻辑。
金额选择器物料
Picker 选择物料
看到这里,也许你会有疑问❓,既然需要写这么多的代码,那我用 vscode 不香吗,用低码的优势和价值提现在哪里?这个问题我们在上述投保页用低码研发的时候也做了重点的对比。我们使用下来,综合觉得有以下几点优势:
在设计物料配置的时候,需要将最常用的属性,放在最前面,一些复杂的、使用频率较低的属性应该进行降级展示甚至屏蔽,保证用户能在第一眼就可以使用到,并且不需要查询额外的文档,配合编排区域的UI实时展示,真正的做到开箱即用
通过复杂场景的实践,我们扩宽了平台的能力的深度,能让开发者在开发中低复杂的续期的同时,不用担心因为后续需求变更导致难以维护的窘境,同时我们也发现,低码目前在研发人员中推广还存在以下几个问题
针对上述实践、总结,我们在年中的时候,适当调整了一些平台的方向,对面向人群,方式做了一定的调整
上面也说到,投保场景作为商业险的核心场景,如果全部采用低码方式进行研发,在用户接受度和使用推广上会遇到很大的困难,即使在已有寿险投保场景落地的情况下。所以我们再思考,是否可以分解页面,将页面分割成组件维度,组件维度的低码可以有效的降低复杂度,让用户更容易接受。保险投保场景的和普通的搭建会场有比较大的区别,普通的搭建会场基本每个组件都是独立的,组件之间可以自由组合,并且组件之间交互相对较少,可以通过事件等机制进行比较弱的关联,组件具备一定的复用能力,可以在不同的会场页面进行复用(banner 组件、轮播组件、抽奖卡片组件)。所以这一类的场景可以通过组件独立研发、页面搭建的形式快速 run 起来,开发者只需要关注组件研发就行。保险的投保页虽然看上去也是通过不同的组件进行累积,但是却有很多不同的地方,拿寿险的教育金进行举例:
综上,完成一个投保页需要通用逻辑+产品定制逻辑+UI 组件几部分区别与常规的搭建组件,每个组件具备完整的子功能,可以直接复用,投保页的组件由于逻辑复杂,一般不会直接放在组件内部实现,而是通过一个统一的公共逻辑去处理,这样做的目的是为了在同一类目的产品中增加复用能力,减少开发量。
正因为投保整体技术方案的复杂性,为了拉齐人生险投保技术方案,保险中台组针对开放的投保方案进行了重构和改造,包括产品配置、前后端架构。前端侧整体思路是将公共部分和业务部分进行拆分,公共部分包含投保框架和公共组件,业务部分包含业务组件
从上面来看,新的投保架构将分工进行了合理的划分,通过框架、公共组件和业务组件进行区分开来,对于业务线来说,只需要专注开发业务组件就行,而业务组件的研发方式也产生了变化,原先需要维护的上千行公共逻辑代码整体以 SDK 形式进行了拆分,留出了扩展点进行业务扩展,剩下的根据 SDK 提供的数据做业务的加工和展示,大大降低了业务研发的难度。
从上面可以看到,新的投保架构设计从将页面内嵌框架后,页面开发变成了组件开发,降低研发复杂度,通过低码研发组件,这个是一个相对比较成熟的领域,我们通过平台的对接,对投保场景做了充分的支持,分成短期方案和长期方案
经过下半年定制开发,寿险所有开放类目共计 22 个组件,5 个类目全部通过低码方式迁移到长江,验证了投保页低码方式从 0 到 1 的突破,完成了低码复杂组件可用的能力,从长远上看,我们需要做到好用,才能吸引其他垂类的用户进行迁移,这个也是我们今年工作的重点。
上面我们说到,低码在场景在常规中低复杂页面、组件有着更直观的优势,对此我们也没有停止这类场景的探索,除了商业险常规的营销组件、中低复杂承接页以外,我们发现轻研发的卡片场景非常适合低码,卡片场景 UI 多变,逻辑简单,需求大,非常适合低码研发场景。为了能够嵌入到 needle 编辑器,我们设计了将低码编辑器作为 SDK 的方式进去,并通过实时出码的方式和 needle 编辑器进行打通,最大程度上复用了 needle 本身的预览+构建编译,同时具备低码完整能力。通过 D2C 作为媒介,低码进入卡片的研发更加具备优势,同时在针对不同的卡片产物(H5 卡片 React,Cube 卡片类 Vue),低码统一的 schema 作为多 DSL 的升维协议,更方便开发者对多 DSL 产物进行研发。通过下半年的和轻研发的整体推广、迭代,加上本身在商业险内部的使用,我们一共完成
算是在保险领域,低码研发模式的一次探索加实践。
在 2B 领域,低码通过附能给非研发人员,大放异彩,解决了生产力的部分问题,在企业研发领域,今年我们通过这个实践,做了一次宝贵、难得的探索,感觉在这个过程中支持、给与过帮助的同学,不管是使用者、合作方、上下游,都对你们说一声感谢,基础前端研发链路,是一个耗时、耗力的工程,从纯代码、低代码、0 代码,甚至当前正火的 chartGPT,未来总在不断的变革中,今年我们还是会不停探索研发提效、体验提升之路,脚踏实地,仰望星空。
👇🏾点击「阅读原文」,在评论区与我们互动噢