红帽白皮书新鲜出炉!点击获取,让你的云战略更胜一筹! 了解详情
写点什么

借助框架和工具让 1 个人可以做 10 个人的事情

可视化辅助编程在蚂蚁的探索之路

  • 2020-04-29
  • 本文字数:5081 字

    阅读完需:约 17 分钟

借助框架和工具让 1 个人可以做 10 个人的事情

提效是企业级前端框架非常重要的目标之一,如何借助框架和工具让 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官网


2020-04-29 16:442829

评论 1 条评论

发布
用户头像
怎么说呢?曲高和寡,点个赞,666
2020-05-07 11:14
回复
没有更多了
发现更多内容

架构实战营 模块四 作业

脉醉

#架构实战营

电商秒杀系统

唐江

架构实战营

千万级学生管理系统的考试试卷存储方案

feitian

【架构训练营】模块四作业

zclau

7月日更总结

耳东@Erdong

个人成长 个人总结 8月日更

架构实战营 毕业总结

TH

架构实战营

架构实战营-模块八作业

fazinter

架构实战营

架构实战营作业 M04

Shawn Liu

模块四作业

绝影

架构训练营

设计千万级学生管理系统的考试试卷存储方案

君子意如何

「架构师训练营第 1 期」

架构实战营 毕业设计

TH

架构实战营

架构实战营-模块六作业

fazinter

架构实战营

架构实战营 - 模块 4- 设计千万级学生管理系统的考试试卷存储方案

蔸蔸

百万量级的架构设计

俞嘉彬

架构实战营

前端之数据结构(五)二叉树

Augus

数据结构 8月日更

架构实战营-毕业设计

大可

架构实战营-模块七作业

fazinter

架构实战营

使用 make 还是 new

Rayjun

Go 语言

模块四作业

河马先生

架构实战营

架构训练营毕业设计—电商秒杀系统

Neil43

架构训练营

Linux之route命令

入门小站

Linux

趁着课余时间学点Python(七)一篇文了解迭代器

ベ布小禅

8月日更

惊!Go里面居然有这样精妙的小函数!

Gopher指北

Go 语言

前端通讯协议:WebSocket和长轮询

devpoint

ajax websocket 8月日更

模块4作业G20210698020270

哆啦A萌

架构实战总结

华仔架构训练营

删除容器报错:Error response from daemon: conflict: unable to delete

liuzhen007

8月日更

千万级学生管理系统的考试试卷存储方案设计

tjudream

redis 架构

【设计模式】装饰器模式

Andy阿辉

C# 后端 设计模式 8月日更

毕设:设计电商秒杀系统

ifc177

【前端 · 面试 】HTTP 总结(八)—— HTTP 强缓存

编程三昧

面试 HTTP 8月日更 HTTP缓存

借助框架和工具让 1 个人可以做 10 个人的事情_大前端_陈成_InfoQ精选文章