干货蚂蚁前端研发最佳实践
为什么要有最佳实践?
不知大家在这些方面是否有疑惑?
前端发展快,每次发布 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 的问题 接服务,比如登录服务,统计服务,问卷服务,评论服务等等