提效是企业级前端框架非常重要的目标之一,如何借助框架和工具让 1 个人可以做 10 个人的事情,要做 10 倍的提效,则要做一些破局的事情。
蚂蚁尝试在写代码(Pro Code)的基础上做可视化辅助编程( Visual Assist Programming ),借助和框架、平台、组件和物料市场的互补,以及用类微前端的架构方案来提供插件机制,以此来提升开发者的研发效率并降低上手门槛。
以下内容根据蚂蚁金服高级技术专家陈成在 GMTC 深圳 2019 全球大前端技术大会上的演讲整理而成。
以下为正文。
我主要分为以下几个方面来讲,可视化编程的优势、可视化编程在蚂蚁的实践、可视化原理的剖析、可视化破局的,最后展望一下未来。
可视化编程的优势
近年来,可视化搭建系统越来越多的被提及,一般来说,可视化搭建系统分为两类:无代码( NO CODE) 和低代码( LOW CODE),这两种的区别是,前者完全不需要写代码,后者需要写部分代码,整体通过拖拽的方式生成。在阿里内部的可视化编程系统有 30 多个,分别解决不同垂直领域的问题。在业界,可视化的应用也越来越多。为什么可视化会火起来?可视化有哪些优势?
1.可视化搭建的优势
可视化搭建优势主要分为以下几点:
所见即所得:通过拖拽的方式生成页面,再通过一些配置就能生成网站;
增删改查,十倍提效:针对垂直领域,可视化就可以进行深入的分装,然后针对常见的增删改查,做到十倍提效也是可能的事情;(搭建系统一般针对垂直领域)
一站式研发:一站式研发通常会管前端的代码,还会管后端代码以及一些服务,开发完了之后还会一键发布上线,处理些回滚等;
专业门槛低:不需要很强的专业技能,也能完成这部分工作;
技术收敛:自己开发网站的时候会去选择和对比,这个平台就会做一个技术收敛,节省成本。
既然可视化编程这么好,以后是不是就可以不用写代码了?
2. 写代码的优势
虽然可视化编程带来了很多便利,但是写大量代码(Pro Code)的优势也很明显,可以对可视化编程做一些补充。
针对可视化编程,写代码的优势在于精确表达,极致体验;
搭建系统针对垂直领域的分装,以此来达到提效的目的,写代码能在分装的基础上更好的实现提效的目的,及产品增值业务;
很多产品不仅有 PC 端、移动端,代码涉及到共享和复用,一站式研发并不能很好的满足部署平台兼容性;
前端技术日新月异,如果把技术分装在平台里,平台更新迭代可能不会像前端技术更新迭代那么快,而很多业务又涉及到更新和迭代,写代码的优势更加凸显。
分析了可视化系统的优势和写代码的优势,接下来我们改怎么去选择呢?
答案显而易见,写代码为主可视化功能为辅。我们应该基于 Pro Code(写很多代码) 去做 VAP(可视化辅助编程)。
基于 Pro Code 去做可视化辅助编程,社区已经有很多先行者。
Pro Code 的痛点又是什么?
文档链路长;
门槛高;
命令行不够友好;
非一站式研发,流程割裂;
研发效率不够高等。
可视化辅助编程在蚂蚁的实践
1. 可视化辅助编程在蚂蚁的实践
基于以上的 Pro Code 的痛点,蚂蚁开发了一个可视化辅助编程工具 Umi UI。主要包括两部分,一是流程,二是功能。
流程是解决从创建开始到最后部署、发布之后等的一系列问题。在社区上还好,如果你要把工具推给内部开发者使用,就必然要解决一些流程上的问题。
功能包含:
- Dashboard;
基础:配置管理、任务管理;
进阶:资产市场、数据管理;
功能闭环:Terminal;
运行态能力:Mini 气泡。
来看一个例子,创建项目。
创建项目其实很简单,即脚手架可视化。
外部创建流程:更新脚手架代码 —>创建项目 —>安装依赖 —>打开项目 —>出错重试。
内部流程相对外部会复杂一点,会走单独的创建、部署和发布流程。
任务管理是基础命令的可视化形式。如:启动、构建、lint、test 等。
配置管理其实是打通文档和工具的一个环节。做配置时就不需要再返回查询文档,就能看到一些具体的选项。
资产管理是可视化编程里面一个比较重要的环节,通过资产管理这个工具可以做一个真正的提效。资产管理包含区块和模板,现在有 antd 的 400 多个 DEMO 区块,以及 antd-pro 数十个模板。通过资产管理,我们把模板都整合进来,这样就可以快速的创建页面。
前面的资产管理 1 是有模板的情况,那么没有模板的情况又是什么样呢?我们以资产管理 2 为例。
没有模板的情况下,我们如何创建页面?
首先,我们先创建一个空的模板,然后选择布局,再在布局里面添加功能区块;
实现这些配置不需要单独的页面去做,如图所示,页面的右下角有一个气泡,通过 Mini 气泡去添加资产,完成所有的事情。
2. Umi UI 使用路径
基于以上所述,我们有两种方式去使用 UMi UI 工具。
(1)正常启动我们的项目,通过预览页去做配置、资产管理、添加等一系列事情;
(2)单独去启动一个命令行,去打开一个完整功能的页面,然后在里面完成具体的事情。
3. Umi UI 的优势与挑战
如图所示,右边的表格显示的是各家可视化框架工具的优势,左边则是 Umi UI 的优势与挑战。
4. 功能矩阵
功能矩阵主要包含三部分:流程、运行态能力、体验和提效。
关于蚂蚁可视化辅助编程工具 Umi UI 到底是怎么实现的,我们一起来探索其原理。
原理解析
1. 架构大图
以下是 Umi UI 的架构大图。
所有操作反馈到用户代码:所有在可视化上面的操作都是最终作用于用户的代码,代码变更后,Webpack 的编译就会重新触发,浏览器就会重新刷新,这其实是一个单项的流程;
插件分客户端和服务端:要实现一个功能需要同时覆盖客户端和服务端的能力;
Mini 气泡:Mini 气泡和用户最终展示的 Dom 结构能有一些更深入的融合。
2. 插件体系
Umi UI 插件体系是 Umi 插件体系的一环。在蚂蚁,我们有几百个插件,如果这些插件需要增加可视化能力,只需要多增加一个编辑态即可。
下图是 Umi Ui 的界面,可以看到我们的界面里面的色块包含:侧边栏、底部状态栏、内容区,插件能力的好处就是可以扩展这些色块。
3. 类微前端的实现
插件的实现有两个特征,即每个功能块都是一个 npm 包,及 npm 包之间的发布节奏不一致。
基于这两个点,我们可以通过微前端的方式去实现插件功能。
扩展方式和现有的微前端方式又有些不同。现有的微前端方案通常基于路由,路由变化之后可以去渲染不同的子应用。在 Umi UI 里,不仅是在路由区域,每个区域都可以被扩展,它更像是跑在浏览器端里面的一种插件体系。
运行态能力是怎么做的呢?
先切换到一个编辑模式,在编辑模式里面就可以看到一些可以插入的“点”,点击这些“点”之后,可以把我们想要的代码插入到具体的位置里面去。
资产添加的实现是基于 AST 解析的。
实现原理步骤:
(1)在 <div> 里面套一个<UserLogin/>组件;
(2)然后它在进入编辑模式后,我们会自动分析出来,我们有哪些占位符。
(3)用户点击占位符之后,会点击一些具体的区块,选择具体的区块之后,我们就会执行添加的操作。
(4)添加之后也会做一个语法输入的解析(需要注意的是:这两个语法解析需要保持相同的语法逻辑),然后把他添加到我们想要的位置去。
关于这一点值得一提的是,这种实现方式其实他有一定的侵入性,开发的时候他会修改用户的代码,大家在实现这套方案的时候保证谨慎和小心。
破局
上面介绍完值得一提的功能点,接下来我想说一下破局。可视化辅助编程一个非常新的东西,要让用户去使用它,就需要真正能打动用户的点,当我们要做可视化编程辅助工具的时候,我们先分析了下目前开发者的时间分布。
根据以上的时间分布图,很明显,我们要做一些提效就要解决上面 70% 的问题,即交互场景和组件相关。
1. 资产市场
接下来,我们通过资产市场来解决组件相关的部分问题。
资产市场主要由以下几部分组成:组件、业务组建、区块、模板;
资产市场要真正做到提效,还有一些关键的点。通过实践,我们发现通过以下点能达到提效:
资产覆盖率达 80%、模板和区块的质量、生产和消费流程。
2. 场景市场
场景市场(如下图)约占开发者 30% 的时间(这里与下图有差异,请以 30%为准)。
右边是一个例子,它像一个 suggestion,我们可以做的很简单,也可以做的很复杂。做复杂的话我们要考虑很多点。我们在快速输入的时候,前面的东西其实是要做取消的,前面的输入可能会产生一些请求,这些请求也是需要做取消的,以及输入和 URL 需要去同步的,还要支持浏览器的前进和后退,像这类场景其实很多,我们要做好的话是需要去覆盖很多小的点,如果每个开发者都去关注这些比较小的点,其实开发成本是件很高的事情。
怎么让开发者写的又快,体验又好,我觉得需要一个类似场景市场这样的事情。
场景市场很多小的点可以去做沉淀,我们现在是通过 hooks 的方式去沉淀。
完成上面这些事情之后,我们来看下一个理想的项目开发流程。
3. 强约束的垂直领域框架
虽然现在的很多框架都有一些约束,但是这个约束其实是很弱的。大家在使用一些框架的时候还是能后去选择很多事情。
针对垂直领域,我们做了一些深耕之后,优化并总结了强约束的垂直领域框架。
基于这一点,我们就可以去做一个类似强约束有很多规则的框架。因为可视化编程工具是基于规则来产出的,有了规则之后,对于可视化辅助编程工具来说,就能去做更多的事情。
我们部门主要是去写前端的中后台代码,我们就会思考,“怎么去写中后台,是要个性话还是要非常集中式的,以及高效的?”所以我们现在的解法是,关键词“强约束”,另外一个是“配置化、约定化”。
(1)强约束
因为现在大家可选的技术方案还有很多,在内部做了很多的约束,大家可以选择不同的数据流,选择不同的 CSS 方案,那么这些技术方案我们是不是应该开放给使用者?尤其团队内部,是不是应该开放给别人去做选择,其实是一个可以讨论的点。我们现在决定的是不开放,所有的东西都是使用相同的,这样, 团队内部就可以保持一致性。
(2)配置化
配置化不仅仅是功能,还有 UI 层。我们看到这是一个 Design Pro 的一个例子,它有 logo、导航、菜单、页面区。每个页面的区别只有页面区这部分,其他部分基本是一致的,所以为什么不让其他区域通过配置自动在框架里面产生。做到这一层之后,其实就是像写小程序一样去写我们的中台代码。
配置层面的不仅包含 UI 层面,还有路由、布局、菜单、导航、面包屑、权限等,这些都可以通过配置化的方式去处理。
(3)约定化
大家通常看到一个框架的时候,可能会觉得它非常的黑盒,不知道为啥就能跑起来了,其实在它背后是有很多的约定。
通过约定,我放一个文件在那边,他就跑起来。
比如说,我有一个 modal 目录,放了一些 hooks,这就是一个数据流的方案。
然后,我放一个 locales 目录,里面去写一些国际化的配置文件,这就是国际化的方案。
我写一个权限点 JS,去定义一些权限,这就是我们的权限方案。
(4)数据流
这是我们简化后的数据流方案,
我们的项目背景是中后台,我们分析了几百个中后台的项目,我们发现大家用全局的数据流还是比较少,基于这种前提,我们把数据流做的很薄。
怎么做把数据流做的很薄呢?
基于 hooks 的极简数据流;
通过框架做约定和简化;
定义基于 hooks,使用通过 useModal。
(5)权限
权限也是类似于数据流,它是在 access.ts 的文件里面,去定义我们的权限规则,然后你可以在数据流的文件里面以及组建层通过 useAssess 去使用,以及可以在路由层做一些配置。
4. 强约束的垂直领域框架 + Umi UI
做了强约束框架之后,我们就有了很多规则,有了这些规则之后,有了约束、配置、规定之后,我们就可以让我们的可视化辅助工具去做更多的事情。
比如,我们可以通过可视化辅助工具,看项目的大图,你可以在页面里了解整个项目的情况,包括项目的 logo、title、路由、组件、权限、国际化、数据流、资产以及布局等。
展望和未来
目前,我们面临三条路:
VSCode 插件;(优点:稳定;缺点:VSCode 插件限制非常多。)
基于 VSCode 封装 IDE;
命令行辅助(保持现状)。
未来,可视化辅助工具我们依旧专注提效。
总结
搭建虽好,写代码更佳;
我们的优势和挑战,包含框架、插件化、运行态能力;
插件化和类微前端前端的架构方式;
新事物需要破局点,破局点来自对开发者时间的探索;
未来三条路的选择。
作者介绍
陈成,花名云谦,蚂蚁金服高级技术专家,入职阿里已有 10 年。之前在淘宝,负责过淘宝首页、宝贝详情、购物车、下单等很多重要业务的前端部分,然后转岗到支付宝,负责 spm、支付宝开发者工具的开发,以及创建了 dva、roadhog、babel-plugin-import、umi 等。擅长的领域有工具、前端框架以及前端性能等,热衷于开源。
活动推荐
提效降本永远是前端不变的话题,在GMTC北京2020我们设置了“大前端工程化”“前端安全生产”等技术专场,在关注前端工程化的同时,也关注前端安全生产,让代码更加可靠。希望通过一线国内大厂的实际解决方案,给大家带来新的思考。详情点击GMTC北京2020官网。
评论 1 条评论