维护一个大型开源项目是怎样的体验?

(我认为)大型开源项目包含以下任意一个或多个特征: GitHub star 数量 1000 +每周都可以接收到多个 issues 或 PR有一些公司或其他项目在生产环境中使用任意一个或多个包管理系统中下载量巨大在项目所在领域中拥有较大关注度 可以从以下几个方面进行回答。 先介绍你的项目,用来干什么的? 在开发和维护的过程中遇到过哪些值得一提的事?有没有什么奇葩的 issue 或者 PR?对你的生活或者工作有没有造成影响(好的,坏的)?
关注者
6734
被浏览
317119

谢邀。现在全职维护 Vue.js: vuejs/vue · GitHub 在某些人眼里可能不算大型吧,不过从用户量来说,全球几十万还是有的。

因为用的人/公司足够多,有足够的社区捐赠和商业赞助,所以现在是独立开源开发者。可以说这个项目已经完全改变了我的生活轨迹。一开始也没想到会能做到今天这个地步。和在大公司对比,没有那么安逸,压力要大一些,但是非常自由,可以做自己真正喜欢的事情感觉很好。

印象深刻的事情

这个项目一开始纯粹是作为练手的轮子,因为当时想要研究 Angular 数据绑定的实现。研究的时候觉得脏检查实在是个不优雅的实现,于是就琢磨如果只支持 ES5 能不能用 getter/setter 实现无缝的依赖追踪。如果算上那时候的第一个 commit,距今已经两年零三个月:initial setup · yyx990803/vue@83fac01 · GitHub 正式对外发布是 2014 年 2 月的事情了。当时也算是抱着『搞个大新闻』的念想小小策划了一下,同时在 HackerNews、Reddit、EchoJS 等地方发了帖子,还给 DailyJS、JavaScript Weekly 等媒体发了自荐。发布后幸运地在 HN 首页呆了一段时间,第一周后拿到了 615 个 star。我对第一周的一些数据做了些统计,还写了篇博客:First Week of Launching Vue.js

当时 Vue.js 其实非常的不成熟,但有一个公司胆子很大地把这个个人项目用在了生产环境里:Optimizely。这家公司国内知道的人可能不多,但他们 B 轮融了 a16z 的 55m,其实是一家准独角兽公司。他们当时的新前端 lead 上任做的第一件事就是把他们基于 jQuery + Knockout 的旧前端用 Vue.js 重写了,还邀请我去过他们办公室聊天。现在回头看来,当时的 Vue.js 问题很多,但多亏了这家公司,让我第一次觉得『卧槽,原来我写的东西还真有别人用!』

另一类有趣的用户则是一群法国的交互开发者。这些人大多是在广告创意类的公司工作,主要的任务就是把网站做得要多酷炫有多酷炫,很多都是从 Flash 背景过来的。对于他们来说 Angular 完全是 overkill,但 Vue.js 却正好。加上对于动画的良好支持也算是 Vue.js 的卖点之一,所以他们用 Vue 还做了不少得奖的交互类网站,比如:Louis Ansa - Interactive Designer (国内可能加载很慢)

再往后不知为什么 Vue.js 在日本也有不少人开始用了,东京一家叫 Cuusoo 的公司有个工程师把他公司的前端用 Vue.js 改写了,翻译了日文文档,居然还组织了 Vue.js meetup... 然后他现在升任他公司 CTO 了 orz... 总之听说 Line 和 Nintendo 也有一些项目用了 Vue.js。

今年 5 月份的时候,Laravel 的作者发了条推,大意是说『我尝试学了下 React,觉得好难用,决定改学 Vue.js 了』。然后 Laracast(一个 laravel 教学视频网站)的创始人做了一系列 Vue.js 教程,于是 Vue.js 突然就在 Laravel 社区火了,貌似现在最活跃的用户都是 laravel 社区的人...

开发中的体验

现在想来,才明白为何一个项目所谓的『成熟』需要时间。今天回头看两年前的代码,那就是一坨渣渣啊。这期间经历了很多摸索着做了个能用的实现,然后去研究其他库的源码,于是恍然大悟为什么他们要这么设计,再把自己的设计改写的过程... 为了这个几乎所有开源的前端库实现我都研究过了,很多次在做大改动的时候心里都会觉得很慌:『之前那么蠢的设计居然还有人用!』0.10 到 0.11 的升级是一次完全的重写,实在是因为 0.10 的设计太幼稚,维护不下去了...

为了能『可持续发展』,不得不强迫自己形成代码洁癖。每一个函数,每一个 hack,每一个 edge case 都要写上注释,怕的就是哪一天自己都看不懂自己当时在干嘛。为了不在修 bug 的时候导致更多的 bug,只能强迫症一般地保证每一个 commit 之前都是 100% 的测试覆盖率。总的来说,能自动化的东西都基本自动化了,比如发布一个新版本也是一个命令自动跑完所有测试,按照 semver 升级版本,然后 push git tag + npm publish。另外还在持续集成服务上对每一个 PR 自动检查代码格式 + 跑单元测试...

另一个很有意思的转变就是从一开始完全想怎么设计就怎么设计,到今天需要考虑各种用例、稳定性、浏览器兼容、向后版本兼容、社区意见等等,整体的设计过程也变得越来越社区化了。以前想做个新功能直接上就是了,现在基本上都会先开个帖子征求下社区意见,大家一起讨论着做。比如这次 0.12 ~ 1.0 的升级,大部分 breaking change 都专门开了 issue 征求社区意见,新的绑定语法更是经历了漫长的几百条评论的讨论...

Issue 和 PR

现在基本上每天起床第一件事就是看邮箱里面有没有新 issue。我用 Inbox 把 Vue 的 issue 专门分了个类别,就当是 todo list,修掉了就勾掉。有时候一口气修了几个 bug 啪啪啪勾掉一堆的时候感觉还是很酸爽的... 当然更爽的是有时候一觉起来一个 issue 也没有 -.-

说到 issue 的类型,实在是一把辛酸泪。刚开始的时候有人开个 issue 就觉得受宠若惊了,到后来时间紧了之后,就越来越体会到对开 issue 的方式对维护者体验的影响。举例来说,有些人开 issue 永远只有一句话,甚至有些直接就是标题:"xxx doesn't work",然后无内容。早期碰到这种的还会记在心上,现在遇到这样的就直接挂个 『请给重现』的 tag,如果几天以后还是没重现就直接关掉。另一种极端就是一些很认真的同学,一个 issue 分几个小标题,『问题描述』、『重现步骤』、『可能的原因』,有些甚至把应该改哪里都帮我指出来了,就差直接开个 PR 了。每次遇到这样的 issue 我就特别想拥抱一下开 issue 的人,希望大家都向这样的同学学习!

印象最深的一个 issue:



最奇葩的 PR:

mini change: removed unnecessary spaces by Jinjiang · Pull Request #1165 · yyx990803/vue · GitHub

^ @赵锦江(勾三股四) 为了混 contribution 已丧心病狂!

对工作和生活的影响


首先,维护这个项目对于个人的技术成长显然是有着巨大的好处的。为了保持项目的竞争力,我需要时刻关注前端最前沿的东西,研究别人的实现;为了保持项目的可维护性,我需要进行各种工程化的实践...

有一个有一定知名度的项目自然在很多事情上也会比较方便,比如当时去 Meteor 面试就是做了个 Vue.js 的分享然后聊了聊天就给 offer 了,并没有叫我翻转二叉树什么的...

生活上,对项目过于投入有一定的负面影响。因为 Vue.js 毕竟是个个人项目,所以经常需要占用工作外的时间,代码写太晚被老婆训斥也不是一次两次了... 还好我在写 Vue.js 之前就已经找到了老婆,各位单身的码农挖坑前还需谨慎!