当前位置：首页 > 每日看点 > 正文内容

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

卡卷网1年前 (2025-01-10)每日看点195

加入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

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

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

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

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

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

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

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

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