本文作者 rebomix 是微軟重要的開源項目之一 Visual Studio Code (常簡稱 VS Code)的維護團隊成員，在此分享了維護 VS Code 過程中的一些見聞和感想，可以讓我們一窺這種由企業支持的大型開源項目是如何運作的。

也希望此文可以讓國內對 VS Code 開發、使用感興趣的同學更多的了解和參與 VS Code 的社區開發。

加入 Visual Studio Code 快一年，趁這個機會聊一聊開發和維護這個項目的感受。以下為個人理解，不代表公司也不代表團隊。

項目

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 從一開始就是一個基于瀏覽器的編輯器，早期一直服務于各個微軟系統中(比如 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 由于渲染閃爍的光標而占用了 13% 的 CPU”。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 和自由工作時間的文化的。