没有天生的高手,更没有永远的菜鸟求知若饥, 虚心若愚

干货分享:蚂蚁金服前端框架和工程化实践


在极客邦科技前两天召开的 GMTC 全球大前端技术大会上,蚂蚁金服高级技术专家陈成发表了《蚂蚁金服前端框架和工程化实践》的演讲,以下是本次演讲摘要。

框架发展历史

2062834391.png

这是我们的框架发展时间线。

2015 年之前我们有 Sea.JS、Arale、SPM 开源技术方案,大家可以有所耳闻。

2015 年我们接入 React,从自研的 Roof 到 Redux 再到开源的 Dva,一步步验证我们的最佳实践,并把这些实践交给开源社区检验。

2017 年开始尝试了新一代的企业级前端框架,Umi 和 Bigfish,前者是从无线业务中长出来的,后者是从中台业务中长出来的。

一个团队出两个框架毕竟不是长久之计,后来老大直接把两拨人调到一个组,于是就愉快地合并在了一起。

1085034751.png

在 Umi 和 Bigfish 时代,我们从刀耕火种的时代跨入了工业化时代。因为在此之前,用户需要接触很多技术栈和细节,在 Umi 和 Bigfish 中,用户只要知道一个框架,剩下的全部不用了解。框架像一个魔法球,把各种技术栈吸到一起,加工后吐给用户,以此来支撑业务。

1633233846.png

在两个框架合并之后,我们的现状是这样:

umi 对外开源,bigfish 对内服务内部同学。

bigfish 扔掉原有实现,改造成 umi + umi 插件集的一个架构。

我们不是第一个这么做的,类似的还有 eggjs 和 chair。这是一种很好的方式,开源和业务两不误。

那么,这是我们的框架终局吗?以及是否还有更好的方式?大家也可以思考下,后面在未来规划区域会有探讨。

37294127.png

这是一些蚂蚁的内部数据:

1100+ 内部应用数

新增产品 80% 都用此框架

包含 100+ 插件数量,社区够活跃,尤其是内部的

1500+ 内部使用者

目前来看,这个框架基本统一了内部的框架使用情况,不仅有不熟前端的 Java 开发,略熟前端的外包,还有资深的前端同学。要获得那么多同学的认可,并不是件容易的事。

为什么我们能成?
那么,为什么我们能成?个人理解,我觉得有几个关键词:

  • 业务
  • 流程
  • 开源

3370647766.png

人是非常重要的一环,甚至比技术本身更重要一些。

那么别人为啥要用你的框架?首先,框架要好用,这是最基本的;然后,使用者尤其是资深的前端同学,还得在这上面找到自己的成就感和 ownership,另外如果绩效漂亮就更好了。总不能别人用你的框架,然后只有你自己一个人的绩效好,那是不会长久的。

我们的解法是插件体系。

1905750517.png

框架不是凭空而来的,需求来自于业务,所以用框架写业务的同学往往能发现框架不足的点,他们可以开发适用于自己业务的框架插件,反哺框架。如果这是通用需求,那就亮了。

框架的内部开发群有 100+ 人,包含大量来自业务线的同学,这就是插件体系的好处,人人都能贡献。

为了让写插件变得简单,我们给框架分了五层架构。

3060398042.png

包含依赖层、插件层、插件集层、应用类型层和部署模式层,大家可在任何一层都可贡献代码,

  • 可以写一个独立的功能插件,比如和某个服务的对接,比如扩展路由的某个功能,比如实现一套特殊的补丁方案;
  • 可以做归类,把一系列插件整理到一个插件集里,适用于某一类的业务开发;
  • 可以扩展应用类型,比如 SPA、MPA、微前端等等;
  • 可以扩展部署模式,比如和不同的框架或平台做结合;

2516422778.png

这是插件生命周期图,包含:

  • node 环境执行的编译时
  • 浏览器上执行的运行时
  • ui 辅助层的编辑时

大部分插件体系只会考虑 node 编译时,我们加上运行时和编辑时的支持,赋予了插件更大的能力。

具体做了什么就不展开了,没个框架都不同,但做的事情其实大体一致,往上说是 html、css、js,往下说还有各种工具的配置,比如 webpack、babel、postcss、dev 中间件 等等。

4247681823.png

下面来看具体如何写一个插件,如果大家有写过 vue-cli 的插件,会发现很类似:

  • 导出一个函数,第一个参数包含我们提供的能力。
  • 可以添加、修改、绑定事件等等。

3213824708.png

我们目前的部分插件,内部流程相关的就没有列出来了,内外加起来应该有 100 多个了吧。

4003690285.png

这是我们的分工表,基本上涉及到了框架和业务的方方面面,很多事情都是由不同的人来负责,大家的参与度也不错。

当然,人总是不够的,很多子项都还处于招人状态。

3514488892.png

我们的框架能成,我觉得另一个重要的原因是我们不仅做功能,还做业务和流程。我不清楚大家是如何走流程的,包括如何切换应用类型,如何和各种后端服务和平台对接,反正我们的还是挺繁琐的。程序员的时间浪费在这里我觉得很不值,所以如果框架能解决这部分,应该会受到欢迎。

我们通过 appType 和 deployMode 两个维护来对接各种场景,用户只要配 deployMode: node 就能对接 node 框架,改成 java 就能对接 java 框架,背后的脏活累活交给框架做。

1842026582.png

最后还有一个原因是我们做开源,我个人是比较热衷开源的,把自己的实现完全透明地展示给社区,包括之前写的工具和数据流方案,也都是从开源做起,因为我觉得开源相比在内网闭门造车,能带来很多好处。

代码质量,不写用例的代码不会有人愿意用。

  • Bugfix 和额外的代码贡献,社区很多人都是愿意参与的,在吸引到足够的人使用之后,框架内部的问题会更快暴露出来,还会有很多人愿意贡献代码和修复 Bug。
  • umi core developer group,我们还组织了社区的 umi developer 群,比如 vscode 插件、create-umi 等等的包,就是由社区同学主导维护的。
  • 另外,开源做地好,也更容易获得内部同学的认可。包括之前做的 dva、现在的 umi,都不是一开始的内部首选,而是后来慢慢逆袭的。

框架大图

1518034749.png

这是我们现在的框架大图:

  • 中间从下往上是社区开源、蚂蚁开源、Bigfish 框架、应用发布流程。
  • 框架层主要就是我们前面介绍的五层架构。
  • 左上主要是资产市场,我们提效的主要手段之前,这在后面会展开介绍。
  • 左下是工程方面的配套设施,编辑器插件、测试、lint 工具等等。
  • 右边是对接的服务,通过框架插件,可实现配置式地对接外部服务,减少接入成本。

拳头功能

下面是我们的一些拳头功能。

资产市场

925475001.png

今年由于大形势的原因,我们比较重研发提效,最好是一个人能干 10 个人的活。关于提效,其中比较重要的是相同的代码不要重复写,要做提取和组件化。而资产市场就是做的这件事。

为了更有效地复用,我们对资产市场分了四级:

  • 组件,指通用组件,就是 antd,在下半年将要发布的 antd@4 里,我们会陆续提取更多通用组件到 antd 中。
  • 业务组件,不能提取通用组件的,我们会提到内部统一的业务组件仓库中。
  • 区块,由组件组成,可以想象成代码片段。
  • 页面模板,由区块组成

我们可以借助工具把区块和页面模板添加到页面中。

3718353815.gif

通过 Umi UI(可视化方式)添加区块的样式。

923426795.png

区块方案其实不是一开始就这样,中间经历了几次迭代。

最初的思路来源是 angular 的一个 theme market,以及飞冰。

1.0 的版本时我们设计区块是页面级的,用户可以在一个页面里写组件、数据流方案、mock 等等,这样我们要做一个基于 antd 的 CRUD 页面就很简单,一个命令把区块拿进来,然后修修改改就完事了。

然后今年我们重新整理了区块方案,因为我们希望区块能更通用一些,比如可重复添加,可无限嵌套,支持区块集,可结合布局,支持可视化添加等等。

这是区块方案的迭代情况,一路踩着坑过来的。

更多内容:http://t.cn/AipJj9oJ

文章评论已关闭!