蚂蚁前端研发最佳实践（推荐）

开篇

准备这个题目时我 google 了下前端最佳实践，排在前面的是讲前端代码规范，语意、可读性、编码规范、空格还是 Tab 等等，我觉得这是我们第一代的最佳实践。

而现在都 9012 年了，最佳实践也经历了很多代的变更，下面是我们在这方面的思考和实践。

自我介绍

目录

为什么要有最佳实践？

不知大家在这些方面是否有疑惑？

这里举一个具体的例子，

可以发现，每个点都会有不少选择，并且有时还真的很难选，因为每个人看待它的角度不同。所以，对于开发者来说，真的有点太难了！他只是想完成需求，然后回家睡觉，为啥需要选这么多，就不能给个默认的吗？

然后，

所以，对于团队而言，保持一致非常重要。

那么，如何保持一致？不同团队会有不同的选择，通常有这几类，

约束能力和迭代能力也是逐步递增。

我们最早应该是用的文档。比如做一些代码约定，用 Tab 还是空格，用两个空格还是 4 个空格，行尾要不要加分号等等，这一类主要靠开发者自觉，所以我觉得不太靠谱，这也是为啥后来有 eslint。

脚手架比文档好点，但也依赖开发者的自觉性，因为还是可以随便改。前几年 React 社区上有不少做的很好的脚手架，但现在基本上都没有活跃的了。

第三种方式是框架，他的约束性可以做的比较强。比如约定用 less，如果开发者用了 sass，就给他报个错。同时相比其他两种方式，还有迭代能力。脚手架交给用户之后是很难更新的，框架则是自己更新后，开发者的项目自动生效。

当然，这三者不是互斥关系，可以都用嘛。

然后如何决定用啥方案，用 SASS 还是 LESS，要不要用 TypeScript，甚至目录用复数还是单数这种极其无聊的事情。

不同团队会有不同的选择，

老板喜欢其实 “很重要”。有些大家吵很久但决定不了的事，往往会很自觉地找老板或者德高望重的同学进行拍板，我们也是如此。

蚂蚁前端的选择

我们在不同时期的最佳实践是不同的，曾经还开发过 spm，不自量力地试图挑战 npm + webpack 组合，虽然失败了，但敢想也是一种勇气。（做 spm 时，webpack 还没出来）

我们有很多方向，然后每个方向又有很多选择，图上是我们目前的选择。

从这里可以看到几点，

为啥要自研呢？

我觉得自研会带来一些好处，

有些开源库看起来美好，但真正用下来会发现坑不少。比如组件的文档工具，目前是选择的 docz 和 storybook，但两者用地都有些说不出来的不舒服，并且和 umi 是两个生态的东西，所以我们正考虑基于 umi 开发自己的文档工具，可能叫 umipress 或者 father-doc 。

沉淀的方式是以框架为主，文档、脚手架、资产市场为辅。

插件和插件集

我们把使用到的技术都沉淀到框架（Bigfish）里。框架像是一个魔法球，把各种技术栈吸到一起，加工后吐给用户，以此来支撑业务。

对于用户来说，Bigfish 框架是唯一依赖。唯一依赖会带来一些实际的好处，这也是我们一直在内部坚持这一点的原因，

唯一依赖的问题就是大而全，虽然看起来挺不优雅，但实际用过之后会发现还蛮香的，除了一开始安装他会有点慢。（这一点我们后续会通过启动器解决）

做了技术栈收敛之后，我觉得对外可能够了，但对内还远远不够。

接流程，让开发者能更顺畅地跑通创建、本地开发、联调、部署、发布和统计

接后端框架，后端可能是 Java、Node 或者 PHP（），不同后端对于前端产物的要求会不同，在框架里做好对接，开发者就不用费心思了

接场景，场景有很多种，在框架层也需做好对接。举一些例子

接服务，比如登录服务，统计服务，问卷服务，评论服务等等

实现方式是一“件”接入，这里的件是插件，一个插件实现一个功能。然后，我们就有了很多插件。

有了插件之后，我们可以筛选一些插件出来形成插件集，以满足某个业务的需求，类似 babel 的 plugin 和 preset，或者 eslint 的 rule 和 config。

**这种方式首先可以满足不同业务的需求。**比如无线业务，会比较关注性能，所以可能会选一个切 preact 到 react 的插件、极速版补丁插件、高清方案、fastclick 等等，形成一个插件集。

**然后还可以满足一个技术的不同实现，**在一个业务类型丰富的大团队中，是允许有不同的选择的。比如数据流，大家的选择可能不同，有些用 dva，有些用 hooks，有些用 mobx，有些自研一套；比如补丁方案，有常规版、极限版，还有终极版。

这是 umi 的插件三态，讲过好多次了，文字稿里就不重复了。

这是 umi 插件的示例。想提一点的是，会用 umi 和会写 umi 插件是两个完全不同的状态，会写 umi 插件，你基本可以魔改 umi 内部 70% 的功能，可以此来达到满足需求业务需求的目的。

资产市场和场景市场

先来看下开发者的时间都去哪了。这是我咨询了一些同事拍脑袋整理的，不太准确。

知道了时间分配后，大家应该知道投时间去解决哪部分的问题，才能真正达到提效的目的了吧。

资产市场用于解决 40% 的开发者时间，非常重要。分为四个概念，

而资产市场要真正达到提效的目的，我觉得还需要解决一些关键的点，才能让整个流程跑起来。

这是内部的资产市场和外部开源的 antd。

这是资产市场通过 umi ui 的方式使用，支持区块、模板以及布局区块。

右图来自开源库 Friend-List，这是一个 suggestion 的实现，他可以简单做，也可以复杂做。复杂做的话，细节点就会很多，比如：

而如果每个开发者都要去关心这些细节，会很难，成本也很高。那么如何让开发者做到又快，产品体验又好，我觉得可能需要场景市场，用于解决 30% 的交互场景需求。

沉淀方式可以用 hooks + 文档的方式；覆盖面从最简单的 CURD 开始，到各种复杂场景。

这里是部分的场景举例。

理想的工作流图。

强约束的垂直领域框架

基于前面讲的插件和插件集的方式，我们已经能够满足各种丰富的业务场景，但是仍然给予了用户很多选择，选择包括选择插件，以及 umi 自身的大量配置项。

对于一些垂直领域，其实还可以做到更好，所以我们最近一直在思考“蚂蚁前端应该如何写中台代码”。

有几个关键的思路，

然后就强约束、配置化和约定化展开聊下。

前面我们已经了解了一致性的重要性，所以何不把这一点做到底呢？

图上只列了一部分。

这里的有些约束甚至会有些反人类，但我觉得约束越强，越能保持大家的一致性，如果我们已经把这条路探地很清楚了，少给选择或许是更好的选择。有些限制还不确定是不是好的方式，但是第一版会尽量把规则收拢地紧一些。

配置化不仅是框架和插件的配置，还包括 UI 。

右图是 ant-design-pro 的图，其中 LOGO、导航、菜单对于 90% 的每个页面来说都是固定的，变化的只有右下的页面区，所以我们何不把固定的部分做成配置呢？

比如：

export default {
  layout: {
    logo: string;
    title: string;
    renderRender: function;
    logout: function;
  },
  routes: [
    {
      path,
      // 菜单配置
      menu: { name, icon, showBreadcrumb },
      // 权限配置
      access,
    },
  ],
}

Layout 是其中一个例子，还可以有更多 UI 的配置化。这也是在一定程度在像 low code 的模式靠，我觉得某些研究地很透的垂直场景下，low code 能让研发更高效。

所以我们把适合做成配置的全部配置化，而不能配置的，则会走约定化。

之前有用过 ruby on rails 框架，特别喜欢那种约定化的编码方式，所以我们希望把他也搬到前端研发流程里。

看起来很黑盒，按照我们约定的方式编码，并且只能这样编码，然后他就能 run 起来。

这是之前在朋友圈看到的图，大家体会下，但这就是我们想要实现的样子。

极简数据流是整体方案的其中一环。

右边是之前做数据流调研时做的整理，发现那么多数据流方案基本都是在这些方案上的差异，而要选哪个就看你对哪些方面比较关心。这部分展开聊比较长，之后会额外写一篇文章介绍。

然后我们还调研了下公司内部的中台项目，发现大部分是简单的 CURD，并且全局数据使用较少，比如通知、登录、当前用户信息等。所以，我们可能是需要一个不那么复杂的，用起来又很简单的数据流方案。

最终讨论下来的方案有几个特点，

总结

文字就不复述了。

这里和大家分享了蚂蚁前端研发实践中三个重要的点，但其实还有更多的点，比如说 UMI UI，如果感兴趣，可以来听我在 12 月 GMTC 深圳的演讲。