186 - 《FunnyCoder 访谈文字稿》

和大圣约了明晚录制，今晚空着就按提纲整理了一份文字稿。

个人介绍

我是陈成，我在阿里的花名是云谦，在网上的 id 是 sorrycc。

我应该算是前端的老人了。毕业之后先是从事美工，当时还有种叫法是平面设计师。工作内容既做 PhotoShop，又写 DIV+CSS+JavaScript。然后 2008 年入职淘宝，小马面试的我，当时的面试题现在看来应该很简单。再到 2013 年转岗来到支付宝（蚂蚁集团）。截止现在，在阿里一共有待了 14 年有余。

我做过大量的业务，也做过不少基础技术。业务上比如淘宝的首页、宝贝详情、购物车，还有支付宝的收银台，都是当时 PV 量极高的产品，做起来很有成就感，因为很小的改动就可以影响很多人。基础技术对外的有 SPM（不知道大家还记得不）、早期的构建工具、Dva、Umi 等，从工具一步步迭代到框架。

目前我负责蚂蚁中后台的前端框架，其底层就是大家在社区上看到的 Umi。我们把非业务层提取到社区开源做，然后把业务层通过插件的方式放在企业内部实现，也算是达到开源和业务的共赢。这和 Egg 是同一个路数。

然后我个人比较喜欢开源、追新的前端趋势和分享，所以会在各个场合做一些分享，以及写写文章。近一年有开始做两件事，1）MDH 前端周刊，2）日更的知识星球。

umijs 是如何做出来的

大厂的开源项目肯定是 KPI 驱动。 先替大家说了。。大厂的开源项目更多的是为了满足业务需要，刚做 umi 时是为了解移动端的需求，目标用户是 ISV，期望让用户使用起来极其简单，所以就做了大量封装，比如构建、入口文件、路由等，让用户只需要写页面，剩下的都不需要关心。这个心智模型其实也一直沿用到现在。

Umi 不是喊着金钥匙出生的官方指定框架，而是从竞品中活下来的。刚做 umi 时，当时还有另一个框架，解的也是移动端的需求，但一个团队肯定不允许两个解相同问题的框架存在，然后过程忘了，最后 umi 留了下来。此后还有出现另一个框架 Bigfish，目标是中后台，但是我们发现移动端和中后台并没有太大需求，两个框架有很多重复工作，于是从组织架构上做了次合并，实现上让 Bigfish 基于 umi。

那会 Umi 的定位还是蚂蚁前端框架。但是后面由于一些不可抗力的原因，我们丢失了移动端市场。所以目前 Umi 的定位是蚂蚁中后台前端框架，但我个人认为，移动端和中后台写代码，并无太大差异，搞两个框架，不仅提高了研发成本，也提高了团队学习成本和培训成本。很多同学既做中后台也做移动端，这是大家就得分别学两个框架。

最后提一下，Umi 是否开源其实有过争执，当时的老板不同意开源。所以大家可以想想看，umi 开源对我的 KPI 到底有没有帮助。

开源项目的灵感是如何出现的

先问是不是。开源靠的是灵感吗？我觉得不是。

开源和闭源一样，都是用来解问题的。有问题才会有方案，才会有开源，所以问题才是关键。很多人拿到有问题的项目或者处于基建荒芜的团队里就会抱怨，但我会觉得那是个宝地，到处都是机会。那问题从哪里来？1）厂内的业务项目，2）社区。

带着问题看社区方案，会有不同的收获。举一些例子。看到 elm 和 choo 我想着用来解 redux 和蚂蚁内部数据流方案不够好用的问题，于是有了 dva；看到 esbuild 我想着用来解压缩的问题，于是有了 esbuild-webpack-plugin；看到 module federation 我想着用来解构建慢的问题，于是有了 MFSU。等等。

有了问题之后，有人会给出很挫的方案，有人会给出很优雅的方案。如何才能做到后者？我觉得其中一点是需要靠长期关注社区养成的良好嗅觉。有足够的输入，才可能输出好方案。

大厂内部开源的流程

有没有流程？有！怎么审批？我不清楚，盲猜标准应该包括，1）解的问题是否有意义，2）方案成熟度，3）避免低水平重复造轮子。

借这个问题聊下开源和 KPI 的关系。我个人的理解是，1）有些团队可能有关，我不清