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

谢邀。现在全职维护 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：

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

对工作和生活的影响

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

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

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

加入 Visual Studio Code - Code Editing. Redefined 快一年，趁这个机会聊一聊开发和维护这个项目的感受，如果大家不反对这是一个 大型 开源项目的话。以下为个人理解，不代表公司也不代表团队。

项目

Visual Studio Code 的目标是做一个 Lightweight Editor，通过的扩展 api，让用户在 VS Code 中达到和 IDE 中接近的开发体验（效率）。

不过很多群众对 VS Code 有诸多误解，我先来一一解答

1. “VS Code 师出 VS，是 VS 找了一群人来重写的，复用了很多 VS 的代码，等等“。很抱歉，并不是这样，半毛钱关系也没有。VS Code 的核心代码，也就是 Microsoft/monaco-editor 是 Erich Gamma 2011 年加入微软后，招聘的一支“全新”的队伍进行开发的。Monaco editor 从一开始就是一个 browser based editor，早期一直服务于各个微软系统中（比如 Visual Studio Online，OneDrive online）。招聘的这支队伍对于 Erich 来说并不是新的，因为大部分成员都是原先 IBM 的老部下，其中几位大爷跟着 Erich 撸了二十多年代码了。
2. "VS Code 是 Atom 的复刻，是对 Atom 的魔改，是 Atom 的一个主题！"。很抱歉，并不是这样，但还是有几毛钱关系的。Monaco Editor 在经历几年的高光期，进入了一个小小的黑暗时代。这时候团队成员开始调研将 Monaco Editor 做成桌面应用，和 Atom 一样，我们首先关注到的就是 node-webkit。必须说 node-webkit 是业界的一缕清风，给这个产业带来了太多的可能性。当然最后我们选用了 atom-shell，也就是后来的 Electron。但就是这个 atom-shell，给大家带来了以上的误导。

最后，我们一定要寻根问祖的话，VS Code 应该是师出 Eclipse（同志们，哎你们怎么扭头走人了，别怕，我话没说完呢）。团队核心的几位大爷，早年就跟着 Erich，在写了几个 Editor／IDE 之后，创造了 Eclipse。正是因为见证了 Eclipse 的兴衰，所以这一次在设计 Monaco／VS Code 的时候，才会如此的克制。Extensibility 不好吗？当然好，但是 Eclipse 的弊端已经在一些竞争对手身上出现啦。

开发／维护

我 13 年加入微软后，就开始接触到 Monaco 了。在使用的过程中踩了一些坑，研究过代码，做过好一些扩展。所以在 VS Code 正式开源后以及上线 Marketplace 后，我就开始动手写一点插件和发 Pull Request。去年五月得空和团队结对编程了两个礼拜后，就加入了 VS Code。

VS Code 的开发几乎完全是公开的。早期我们还通过 User Voice 收集反馈，但我们早就把它关掉了，所有问题的处理都放在 GitHub 上。我们的 Yearly/Monthly plan 都以 issue 的形式呈现 Microsoft/vscode ，而我个人正常的开发节奏是这样的：

计划

在上一个 milestone 快结束、新的 milestone 开始的第一周，和老板沟通新的 milestone 自己想做的功能。以及自己要不要休假。

Debt Week

我们把新 Milestone 的一周当作 debt week，集中处理一些技术债，以及为一些插件做点微小的贡献。我一般会花一点时间在 Vim 插件以及我自己的 Ruby 插件上。

开发

这之后就是两到三周正常的开发。每天起床得先把自己头上的新 issue 都 triage 一遍，遇到紧急的得先修，不然就继续完成自己的 feature。

Inbox Tracking

我加入团队的时候，我们只有 1700 个左右的 issue，现在已经破 4000 了（大部分都是 feature request）。GitHub Inbox 在这种情况下是无用的，我们的做法是每周会有一名同事，负责 GitHub 的新 issue，assign 给合适的 owner。我已经当过三次 Inbox Tracker，只能用可怕来形容。每天一睁眼就是一百多个 issue 要处理，一点都不想起床。

Endgame

我们在 milestone 的最后一周 endgame 会对新 feature 进行各种花样的测试，对这个 milestone 关掉的所有 issue 进行验证。全部完成后，每个成员书写自己负责部分的 release note。最后 Endgame master 会到后台网站发布新的 Stable 版本。

印象深刻的事

当之无愧就是 VS Code uses 13% CPU when idle due to blinking cursor rendering . VS Code 是基于 Electron 的，而 Electron 则基于 Chromium。这样的话，Chromium 的锅有时候得我们来背。

VS Code 里的编辑区域并不是 textarea ，全都是 mock 的，这也是主流做法，Ace、CodeMirror、Atom 无不例外。理由也很简单，要实现Tokenize、高亮、Partial Render、Line Wrap，自己控制渲染肯定是最方便的。为了尽可能模拟 textarea，我们模拟了光标。最开始这个光标的跳动，是通过 JavaScript 来控制光标的 opacity。后来社区给我们贡献了一个 pull request，使用 CSS animation 来调整 opacity。实现上来说肯定是比 JavaScript 版本更优雅，同时也提供了四五种不同的光标跳动的选项。

但谁知道，Chromium 对于 CSS Animation 是有巨大的坑的。比如你写的 animation 是每秒改变一次 opacity，但是 Chromium 会根据刷新率（比如 60hz）来检测页面上的 animation。虽然我不知道 Chromium 做了什么，但是你可以看到每16ms，Chromium 就会吃掉一点你的 CPU 和 Battery

真的是一点办法没有。我们起初没有发现这个问题，直到 broccoli 的作者 Jo Liss 给我们发了 issue，并且在 Twitter 上爆我们，瞬间就成了 Twitter 上大新闻。连 Miguel de Icaza 都点赞了，真的是。。。

当时我刚吃完晚饭，但是由于这个事情在我的防区，我只好开电脑 troubleshoot。最后发现是 Chromium 的 bug，开了两年多了，我只好告诉 Jo Liss，这锅我们不背，但是我们会修的。

结果之后好事者把事情捅到了 HackerNews，瞬间成了当天大新闻，还上了 TheRegister 小报。所有人都开始讨论使用 Browser 技术做桌面应用是不是正确的选择，撕的不亦乐乎。

你们撕的倒是开心了，我那几天给各种老板解释什么是跳动的光标，忙的跟狗一样。好在后来 Chromium 的 PM lead Paul Irish 留言表示这是他们的 bug，算是完美收官了。

有没有什么奇葩的 issue 或者 PR？

1. 你们猜大家看到中文写的 issue 会找谁来翻译？
2. 有些朋友提交了 PR，根本不管你给的建议，自顾自的更新修改。这样的 PR 根本不可能 merge，但是我们给的尽可能 polite 的建议，有些朋友真的把它们只当成建议。。。
3. 再一次说到跳动的光标，这个始作俑者是社区的朋友，看起来也是非常 neat 的实现，谁知道就踩了 Chromium 的坑呢。。。

关于中文 issue 的问题，VS Code contribution guide 写的是比较清楚的，请大家用英文提问。但是鉴于中文用户量巨大，加之人总有英文不够用的时候，VS Code 也会经常看到中文问题。我有这样一些想法

1. 写中文我个人觉得问题不大，毕竟 GitHub 是我们几乎唯一的反馈渠道，不能要求用户必须会英文。
2. 写中文的确增加了我本人的工作量，所以能写英文，还是尽量写。
3. 但如果你觉得需要严重的 Google Translate 的帮助，我建议还是写中文，并且 cc 我。不然可能翻译出来最后谁也看不明白，或者误解。
4. 我老板问我，为啥中文 issue 几乎把所有东西都写在标题里，然后 issue 描述留空。我真的不知道该如何回答。如果用中文写 issue，并 cc 我，请保证把reproduce steps 写好，一步一步用中文写清楚，这总没难度吧？
5. 如果第四步做不到，还要我解决问题，请考虑请我喝啤酒吧。

生活

大家都喜欢开源，但开源贡献者大部分时候是在做义务贡献。这么来看在微软搞 VS Code 就是一件愉快的事情，毕竟有人给你付工资让你做 open source。而且再也不用上班搞一套代码，回家之后私下自己在 GitHub 上面逛游，搞别的项目，上班和下班后可以在同一块土地上耕耘。

当然这样缺点也很明显，就是生活和工作往往难以分开。工作是一周五天，一天八小时，但是 GiHub issue 从来都是 7*24。遇到棘手的问题的时候，很难放任不管，哪怕已经回了家。不过也正是因为项目的特殊性，我们组还是有比较好的 remote 和自由工作时间的文化的。

---

补充

1. 添加了对中文 issue 的看法。