首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

借助框架和工具让 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 等。擅长的领域有工具、前端框架以及前端性能等,热衷于开源。

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/PvG7ZVC0U9WJW0Qz3Q6D
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券