阅读 1684

在 GitHub 学习,成长为自己想要的样子|HelloGitHub 访谈

本文首发于「HelloGitHub」公众号,搜索「HelloGitHub」点击关注解锁更多宝藏!

万事开头难,我们经过长期的策划和筹备,终于推出了 HelloGitHub 采访系列「开源项目作者的访谈」。这是一个采访个人开源项目作者的栏目,内容侧重于开源项目作者与开源的故事。

我们深知想要做好一个开源项目不是一件简单的事,同时也不止一次遇到过想做一个开源项目却不知道从何下手,那么「HelloGitHub 采访」希望通过分享优秀的个人开源项目作者的经历以及故事, 让读者了解更多开源项目背后的故事,做开源项目的乐趣、困难、挫折以及收获。

最后,也希望通过这个系列让大家认识:

优秀的开源项目背后,那个对开源充满热爱而且特别可爱的人。

HelloGitHub 访谈,第一期的嘉宾:iamkun(朱昆)

在 GitHub 上学习、成长为自己想要的样子——iamkun

iamkun

故事开始之前,我们先来认识下我们的嘉宾:

姓名:朱昆
常用 ID:iamkun(不是蔡徐坤的坤哟~)
GitHub:https://github.com/iamkun
开源项目:
    - https://github.com/iamkun/dayjs
    - 语言:JavaScript
    - Star:34.8k
    - 收录于 HelloGitHub 第 26 期
目前是阿里 Element UI(49.9k star)社区负责人
复制代码

iamkun & 开源项目

Day.js

🎙️ :说到 Day.js 我们一定会想到 Moment.js,而 Day.js 的特性之一便是 Moment.js 没有的极简和轻量,这当中是有什么故事吗?为什么在 Moment.js 盛行的 2018 年,选择开源 Day.js 呢?

昆哥:其实一开始我并没有想要做一个开源项目之类的想法,纯粹是一次公司业务需求,想把项目优化下让加载速度更快一点,然后发现整个项目中用了 Moment.js,但是我们并没有使用它的全部功能,而只是用了部分功能,所以想着能不能搞一个精简版的 Moment.js,就这样我们优化了项目之余也有了 Day.js 雏形。这里要说下 Day.js 的命名了,一个项目的名字首先要好记,本来想叫 Date.js(前端嘛命名总是带个 js,常见的就是 Node.js 了),不过有点遗憾被人抢占了,想着这个项目要和日期有关最后就叫了 Day.js。

回到上面提到的那次优化,我们业务用上“初代” Day.js 之后 js 压缩之后是原来的 1/30,也算是达成了优化的目标。

就是这样仅仅是公司的优化需求,产生了 Day.js。至于为什么是 2018 年,都只是个时机罢了,刚好业务优化需求,加上当时网上也没有好的优化方式,网上大多数的解决方案都是基于 Moment.js 去进行优化,而没有人想到去写个简化版的 Day.js(笑:大概是没有人想到重新“造个轮子”吧)。正好,公司那段时间也在鼓励开源,然后我们就想着反正都写了,对吧,那不如索性发到网上去大家一起用好了,毕竟我们在项目中用了 Day.js 确实挺好用。

当然,在完全没有推广仅开源的情况下,不出所料,Day.js 起初一个 star 都没有 :) 开源不易。

Element UI

🎙️ :除了 Day.js 这个身份之外,iamkun(昆哥)的另外一重身份是 Element UI 社区负责人。而一提到 Element UI,一般前端同学都会问:它还在开发吗?还在维护?这里方便透露下 Element UI 目前的开发进度和版本规划吗?

昆哥:Element UI 其实一直在维护的,只是它作为进入成熟期的开源项目,不会像初期那样频繁迭代,主要是以性能优化和 bugfix 为主,毕竟 Element UI 有非常多用户在生产环境上使用它,还是以稳定为主。

在保证用户生产环境稳定之余,我们也有同步在做基于 Vue3 的 Element Plus 版本,重大的不兼容升级和新组件,新 UI 都会在 Vue3 里更新,毕竟按照现在的社区趋势,Vue3 也是大势所趋。所以,未来我们的主要开发精力会随着 Vue3 的普及,慢慢地转移到 Element Plus,当然用 Element UI 的小伙伴也不用担心,Element UI 会一直处于一个维护的状态,会有 bugfix 的 pr 合并进来,直到慢慢地所有的 Vue2 的生态迁移到 Vue3。这里我们也欢迎其他小伙伴一起来做 Element UI,简历这边有请:kunhello@outlook.com

iamkun & 开源之路

🎙️ :我看到你在 GitHub 上还有几个有意思的前端项目,比如:盖楼游戏等。而时间节点都很凑巧,是三年之前开始的?所以 iamkun(昆哥)你是怎么走上开源条路的呢?以及,在你看来「开源」到底是什么呢?

昆哥:为什么开源时间点都是 3 年前呢?因为在那个时候,我刚刚入门前端,有了自己的 GitHub,就想着把自己写的好玩的一些东西就会放在 GitHub 上面。

其实我开源出来的东西主要都是个人兴趣,换句话说,开源是我的一种学习方法。举个例子,我要实现一个需求,相比用现成的库,我会更喜欢自己造轮子,把里面每一个东西用最纯的 JS 写出来,这样子去更好地了解它里面的原理。当然,纯粹地去造一个干巴巴的轮子,其实是一件非常枯燥的事情,所以我一般会给它找一个场景,像上面盖楼游戏就是我开始学 Canvas 的时候写的。通过试着写一个游戏来理解 Canvas 当中的原生 API,盖楼游戏 GitHub 地址:github.com/iamkun/towe…

一开始走上开源这条路,正如上面说的有了 GitHub 之后就想让贡献墙好看点,所有有什么稀奇古怪好玩的东西都会往 GitHub 上面放。但后来为什么越来越喜欢做开源呢?因为我发现如果你真是很用心地把你的项目推到社区,是真的会吸引来很多志同道合的人,他们会很乐意帮你把项目做得更好,也非常乐意去帮你 review 代码,去帮你完善你之前可能做的不是很好的地方

所以说,开源其实更重要的是一个 idea,就是你想做什么,你完全不用担心自己的代码写得好不好,或者说自己的能力能不能把这样的一个东西做起来,只要你有这个 idea,只要你愿意去做,开源社区的力量就是这么的强大

🎙️ :做过开源项目的小伙伴都了解,一个项目获得成功,姑且以 star 数和 commit 数为衡量标准,是一件不容易的事情。搜遍全网,Day.js 在开源之后,iamkun 你并没有大张旗鼓,花很多精力在推广上面,但三年之后它成长为了一个 30k+ star,1.3k+ commit 的项目,当中是有什么黑魔法吗?

昆哥:Day.js 缘起于一次业务优化,开源之后其实很长时间里没有做推广,就只是内部在使用。我们一直觉得酒香不怕巷子深,就那样开源放在 GitHub 上,结果一个 star 增长都没有。后来我们觉得酒香也怕巷子深,就是开源项目你光做出来其实只是它的第一步,后期的推广还是非常重要的。

当然,我个人觉得 Day.js 能火起来主要是因为两点,第一点就是天下苦 Moment.js 久矣,就想上面提到的,其实在网上搜一搜,很多的人都在说 Moment.js 体积很大,而且它这种可变对象对于调试和开发非常的不友好。但是,社区的各个方案基本上都是在考虑怎么对 Moment.js 本身进行优化,比如:把这些 locale 文件都去掉,或者基于一些 Webpack 的插件去优化 Moment 本身。也可能没有人想着说我再写一个精简版的 Moment,因为这样听起来就是一个没有意义的重复造轮子的行为。

但是,社区上对于优化 Moment 也是一个很经典的话题了,大家有各种各样的尝试方案,所以我觉得 Day.js 能火起来,第一点还是因为大家都觉得 Moment 很好用,但是 Moment 也有它非常不友好的地方。

另外一点可能就是有一点点机缘巧合了, Node.js 社区有一个大神叫 TJ(github.com/tj),这个人非常的厉害,就是我们用的 KOA、Express 这些知名框架都是他写的。在我也不知道为什么的情况下,TJ 大神给 Day.js 点了个赞,就在 Day.js 完全没有推广,完全没有什么 star 的时候,他给点了一个 star。然后,TJ 大神的这一次点赞给 Day.js 带来了几千 star,然后 Day.js 就开张了。

说个小花絮,后来我在推特上问 TJ 大神为什么那时候给我们点了个 star,他说:只是觉得 Day.js 有意思。

但是,真要说 Day.js 它能变成今天这样一个 30k 多 star 的项目,它一方面和前期的努力迭代、推广有关系,另外一方面其实我觉得更重要的是要坚持去做它、维护它

Day.js 其实刚开源的第一年也没有那么的火,也没有特别多的关注,我真的就只是想把它开源出去、把它做得更好,当做自己的一个产品去运营、维护以及迭代它,所以慢慢坚持下来。而社区上的人,用过 Day.js 之后觉得挺好用,就会自发地帮你去推广、安利,慢慢地 Day.js 就被大家知道并且接受了。

  • 机缘巧合 node 社区大神 tj 点了个 star 为项目带来了几千 star
  • 天下苦 moment 久已
  • 只要坚持,star 就会一天天变多,但这里涉及到一个反馈的问题

🎙️ :无论是 Day.js 还是 Element UI 都可以说是一个前端明星项目,且用户体量不小,在维护大型的开源项目上你有什么经验可以分享吗?

昆哥:前面也提到,一个项目被人用在生产环境,第一点要保证的是产品的稳定。尤其是 Day.js 和 Element UI 这种用户体量巨大的开源项目,其实功能什么的都是次要的,最重要的是每次发版的稳定性,因为可能一个很小的失误,就会导致别人线上的项目直接就挂掉,这样就很尴尬。所以,比较重要的一点就是 semantic version,就是 Node 社区大家比较推崇的 a.b.c 这样的版本号。有不兼容的版本一定要通过版本号去区分,而不要你明明是一个不兼容的更新,但只是发了一个非常小的 patch 更新,这样对于你的用户是非常不负责任的,而且也很容易引发社区的舆情。

其次就是说,当用户量大起来了,开源项目其实就不只是你自己的项目,而是一个社区大家的项目了。所以,当你想加新功能、改功能或者移除功能的时候,最好不要直接就改代码发版本,而是去开一个 issue,和社区的同学一起好好去聊一聊、讨论一下这个东西。这样子的话,接受社区的意见可以让你的项目在社区走得更远,而不是成为你自己一个人的玩具。举个例子,像 Day.js 中各个国家本地化的模块,比如语言翻译、国家的大小年,大部分是依赖于社区中身处当地的同学,他们对这块的了解肯定比我要深。

当然,最后一点也是我觉得最重要的一点,不要想着这么大的项目可以完全靠你自己一个人做完,首先每个人的力量是有限的。其次,大家都是有本职工作的,都是利用自己的业余时间做开源。而像我 Element UI 加 Day.js 每天有超过三、四十个 issue 和 pr 需要处理,如果光靠我自己一个人,我是没有能力完全处理完的。这就要讲到开源社区的好处了,真的会有很多热心的小伙伴,他们非常乐意去帮你一起维护社区、做周边生态,去把整个项目做好。所以说,要相信社区的力量去多多发展和壮大你的社区

再补充一条,其实不管是 Day.js 还是 Moment.js 都有一个很重要的经验,一定要靠各种各样的自动化工具,比如自动化测试、自动化的 lint,以及其他自动化流程,去尽可能过筛掉一些低质量、不合格的 pr,这样子就可以保证需要你人肉来 review 的 pr 它不会出现代码运行不起来、把你之前的逻辑改坏掉,或者说 pr 质量非常差、代码写得非常乱,诸如此类问题。一方面可以提高你整个 pr 的质量,另外一方面也可以大大地减少维护者在这个项目维护上面的时间。

  • semantic version
  • 重大改变先开 issue 讨论,可能自己的想法是错的
  • 发展社区力量,一个人是忙不过来的

🎙️ :一个开源项目的持续发展,除了仰仗维护者自身的努力之外,项目的 Contributor(贡献者)也是一个不可小觑的力量。Day.js 和 Element UI 都拥有过百的 Contributor,当中也不乏一些国际友人。在和 Contributor 的沟通中,有什么有意思的故事发生吗?和国内外的 Contributor 日常交流中,除了语言的不同,有什么编程、设计思维上的不同吗?

昆哥:我这里也是个小样本,根据和 Day.js 海外开发者的接触,我觉得国外的程序员比较熟悉开源的游戏规则,或者说是玩法、流程,比如,他们提个大 pr 之前会先开 issue 问问这个东西可不可以做,会 at 项目负责人或者是 maintainer:他可不可以去提这个 pr。我觉得这样做其实还挺重要的,因为如果你上来一个 pr 哗啦啦地把项目改了一大半,但又不是社区期望的方向,自然是很可惜但只能抱歉地关掉 pr,此外,也白白消耗了贡献者的开发精力和热情。

而,我接触到这些国外的程序员,感觉他们更倾向这样的一套玩法:先去跟你交流,然后再去做。

还有一个个人的感觉,也许是我的错觉,我总觉得国际友人他们的空闲时间比较多,反映出来就是他们在开源项目的不管是参与度,还是参与的深度或是频率都感觉会比我们这边(国内程序员)要多一些。简单来说,不管是贡献者,还是他们贡献的代码量,包括和你一起讨论问题、code review 的参与度,国外的程序员都比较多。一方面可能是他们的兴趣,还有一方面海外的程序员也可能确实比较闲,我觉得。

  • 一部分人很熟悉开源的游戏规则,提 pr 之前会先开 issue 问问可不可以做
  • 感觉上他们空闲时间更多,更愿意贡献

🎙️ :那有统计过 Day.js 国内和海外的一个 contributor 比例吗?以及,Day.js 是如何吸引那么多海外的 contributor 呢?

昆哥:大概是 9:1,国内的不到 1/10 的这样一个比例。其实,吸引海外 contributor 算是国际化的一部分。一开始,我在做 Day.js 的时候,整个社区 issue 或者 pr 我都是要求用英文来书写,如果是中文的 issue 我一定会关掉,或者让他们改成英文的标题。因为,我期待的是既然做开源项目,大家都用英文这种 GitHub 上更通用的语言会更友好。另外一点,其实也是我觉得比较遗憾的事情,就是 Day.js 从一开始的开发到推广,其实我自己这边的渠道全都是国内的渠道,即便这样一个国内的项目又在国内的渠道推广,但目前看来,Day.js 真正参与进来开发的人大部分 9/10,或者是 8/10 都是国际友人,可能还是两边的想法不太一样。

iamkun & 前端学习和提高

🎙️ :在进行采访之前,HG 向小伙伴们收集了下想问 iamkun(昆哥)的几个问题。由于时间问题下面只问其中的一个问题:前端技术日新月异,你在平时的工作、生活中,主要会从哪几个方面来提升自己的技术水平呢?

昆哥:我是从刚入行就注册的 GitHub 账户,并且开始对开源社区感兴趣。一直到现在,自己挺多的业余时间都是在开源社区里学习和成长。我个人是很喜欢在社区造轮子,并且分享自己的轮子来提升技术。

首先通过造轮子,一方面你可以了解一些你不熟悉的技术细节,它的底层原理是什么?另外当你把造出来的轮子分享出来,并且有人来看的时候,就形成了一个非常好的互相学习氛围。

通常社区上的同学的水平都是比你高的,所以不管他是从架构对你提出的建议,还是对于你一些不太优雅写法的纠正,包括他们给你贡献的 pr 其实都是非常好的契机让你去学习和提高自己技术。

这也就是一种比较良性的正向反馈,换句话说,既然说做开源,如果你东西做出来了,然后没有人去看,自然而然你也不会有什么动力去坚持维护下去,对吧?但是如果说,你做出来的东西,有人在用,有人给你反馈,你就会觉得我做这个东西原来还是有一点点价值,这样你就得到了一个正向反馈,你就更愿意去花精力把它做得更好。

在这样的一个过程中,其实你就学习和成长了,而且这里的学习和成长还不仅仅只限于题目中说的前端成长,更多的是让你从一个完整的产品角度去看待、规划产品。

比如说,你的产品怎么帮用户更好地解决问题。这可能就回归到了技术的本质,就是技术本质并不是说比较谁的技术好,谁的技术不好,技术它也只是一种手段去解决一个问题,让这个产品被更多的用户所接受。

最后

以上就是本次 HelloGitHub 的访谈的全部内容了,首先感谢 iamkun(昆哥)接受 HelloGitHub 的访谈,分享自己和开源的故事、经验。

在 GitHub 上造轮子分享自己的作品,坚持不断地迭代维护。然后通过开源社区的力量让它越来越好,同时你也会越来越强而且不单单是技术上的成长!

这里是 HelloGitHub 的访谈节目,每期和个人开源项目作者聊聊他们与开源的故事。如果你也想和更多的小伙伴分享你和开源的故事,那就联系我们吧。

报名链接:wj.qq.com/s2/8414291/…


关注 HelloGitHub 公众号 第一时间收到更新。

还有更多开源项目的介绍和宝藏项目等待你的发现。

文章分类
前端
文章标签