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

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

<>项目

VisualStudioCode的目标是做一个LightweightEditor，通过的扩展api，让用户在VSCode中达到和IDE中接近的开发体验（效率）。

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

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

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

<>开发／

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

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

<>计划

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

<>DetWeek

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

<>开发

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

<>InoxTracking

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

<>End

我们在milestone的最后一周end会对新feate进行各种花样的，对这个milestone关掉的所有issue进行验证。全部完成后，每个成员书写自己负责部分的releasenote。最后End会到后台发布新的Stale版本。

<>印象深刻的事

当之无愧就是VSCodeuses13%CPUwhenidleduetolinkingcsorrendering.VSCode是基于Electron的，而Electron则基于Chromium。这样的话，Chromium的锅有时候得我们来背。

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

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