干货蚂蚁前端研发最佳实践

为什么要有最佳实践？

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

前端发展快，每次发布 Umi 版本时，除了点赞，还有人求别发，表示实在学不动了。右边这张图是之前的朋友圈看到的，转到公司群里，有共鸣的人不少，说明一定程度反应了现在前端社区的情况。 面对海量“轮子”，我应该学哪些，不学哪个？，我的前端知识点学习列表已经是完全学不完的状态，比如社区上光数据流方案就有几百个，其中值得一看的也有四五十个吧。 然后，大家在创建项目时，是否也有过选择困难？

这里举一个具体的例子，

基于 React 的框架 CSS 方案 数据流 请求库

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

然后，

如果每个项目都要选，我觉得会很难。当然，也有人可能会觉得是一种乐趣。 而对于团队而言，如果每个项目的选择还都不一样，那么团队的研发成本和效率都会是问题。想象一下，如果一个同学换个项目组，需要接触完全不同的技术栈。

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

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

脚手架

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

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

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

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

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

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

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

STAR 数，大家通常会选 STAR 数多的，社区认同感很重要，比如 DVA 在蚂蚁的推广就是先从社区做起的 简单 vs. 规范，有人会选择概念少而简单的，有人会选择概念多但看起来更规范的 先入为主，先占坑的往往具有优势 老板喜欢，??

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

蚂蚁前端的选择

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

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

从这里可以看到几点，

选择的内容基本上是社区主流的，不脱离社区是基本原则 很多子方向都选择了自研或者正在考虑自研

为啥要自研呢？

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

自主权 vs. 成本，在拥有自主权的时候，需要评估其带来的成本，以及潜在的弃坑可能 定制化， 需求满足，社区方案有时并不能很好地契合我们的需求，尤其当我们很深入地去使用的时候 售后服务，出错是能找到 owner 的同学是非常重要的一点

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

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

框架具有更强大的约束性和迭代能力，这也是我们所需要的 对外是 Umi，面向社区 对内是 Bigfish，在 Umi 的基础上解决流程和业务问题

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

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

技术收敛，保持团队开发模式的一致性 无痛升级，我们既要保持对社区的技术跟进，又要让业务项目跟上步伐，这些中间的屎只能让框架吃掉，让开发者尽可能地无痛升级 应用治理，相比散落的遍地开花的依赖，唯一依赖可以让我们更好地推动用户升级框架，因为只要管一个点即可

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

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

接流程，让开发者能更顺畅地跑通创建、本地开发、联调、部署、发布和统计 接后端框架，后端可能是 Java、Node 或者 PHP（??），不同后端对于前端产物的要求会不同，在框架里做好对接，开发者就不用费心思了 接场景，场景有很多种，在框架层也需做好对接。举一些例子 SPA 应该是目前用地最多的一种应用类型，但有时也会不满足需求 比如运营页面，多个页面之间没有一点点关系，也不需要互相跳转，用 SPA 就没有意义，这时候 MPA 可能更适合 比如语雀，我们的文档平台，他有前台、有后台、有 PC 端、有无线端，如果整体是一个 SPA，不仅尺寸大，公共依赖的提取是个问题，不同场景之间可能还会相互影响，这时候，多 SPA 的组合会更适合他 微前端前面已经提过 SSR 和 Prerender 则是为了更好的浏览器性能，顺便解决 SEO 的问题 接服务，比如登录服务，统计服务，问卷服务，评论服务等等