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

也希望此文可以讓國內(nèi)對(duì) VS Code 開發(fā)、使用感興趣的同學(xué)更多的了解和參與 VS Code 的社區(qū)開發(fā)。

加入 Visual Studio Code 快一年，趁這個(gè)機(jī)會(huì)聊一聊開發(fā)和維護(hù)這個(gè)項(xiàng)目的感受。以下為個(gè)人理解，不代表公司也不代表團(tuán)隊(duì)。

項(xiàng)目

Visual Studio Code 的目標(biāo)是做一個(gè) Lightweight Editor，通過的擴(kuò)展 api，讓用戶在 VS Code 中達(dá)到和 IDE 中接近的開發(fā)體驗(yàn)(效率)。

不過很多群眾對(duì) VS Code 有諸多誤解，我先來一一解答

1、“VS Code 師出 VS，是 VS 找了一群人來重寫的，復(fù)用了很多 VS 的代碼，等等“。

很抱歉，并不是這樣，半毛錢關(guān)系也沒有。VS Code 的核心代碼，也就是 Microsoft/monaco-editor 是 Erich Gamma 2011 年加入微軟后，招聘的一支“全新”的隊(duì)伍進(jìn)行開發(fā)的。Monaco editor 從一開始就是一個(gè)基于瀏覽器的編輯器，早期一直服務(wù)于各個(gè)微軟系統(tǒng)中(比如 Visual Studio Online，OneDrive online)。招聘的這支隊(duì)伍對(duì)于 Erich 來說并不是新的，因?yàn)榇蟛糠殖蓡T都是其原先 IBM 的老部下，其中幾位大爺跟著 Erich 擼了二十多年代碼了。

2、"VS Code 是 Atom 的復(fù)刻，是對(duì) Atom 的魔改，是 Atom 的一個(gè)主題!"。

很抱歉，并不是這樣，但還是有幾毛錢關(guān)系的。Monaco Editor 在經(jīng)歷幾年的高光期，進(jìn)入了一個(gè)小小的黑暗時(shí)代。這時(shí)候團(tuán)隊(duì)成員開始調(diào)研將 Monaco Editor 做成桌面應(yīng)用，和 Atom 一樣，我們首先關(guān)注到的就是 node-webkit。必須說 node-webkit 是業(yè)界的一縷清風(fēng)，給這個(gè)產(chǎn)業(yè)帶來了太多的可能性。當(dāng)然***我們選用了 atom-shell，也就是后來的 Electron。但就是這個(gè) atom-shell，給大家?guī)砹艘陨系恼`導(dǎo)。

***，我們一定要尋根問祖的話，VS Code 應(yīng)該是師出 Eclipse(同志們，哎你們?cè)趺磁ゎ^走人了，別怕，我話沒說完呢)。團(tuán)隊(duì)核心的幾位大爺，早年就跟著 Erich，在寫了幾個(gè) Editor/IDE 之后，創(chuàng)造了 Eclipse。正是因?yàn)橐娮C了 Eclipse 的興衰，所以這一次在設(shè)計(jì) Monaco/VS Code 的時(shí)候，才會(huì)如此的克制。Extensibility 不好嗎?當(dāng)然好，但是 Eclipse 的弊端已經(jīng)在一些競(jìng)爭對(duì)手身上出現(xiàn)啦。

開發(fā)/維護(hù)

我 13 年加入微軟后，就開始接觸到 Monaco 了。在使用的過程中踩了一些坑，研究過代碼，做過好一些擴(kuò)展。所以在 VS Code 正式開源后以及上線 Marketplace 后，我就開始動(dòng)手寫一點(diǎn)插件和發(fā) Pull Request。去年五月得空和團(tuán)隊(duì)結(jié)對(duì)編程了兩個(gè)禮拜后，就加入了 VS Code。

VS Code 的開發(fā)幾乎完全是公開的。早期我們還通過 User Voice 收集反饋，但我們?cè)缇桶阉P(guān)掉了，所有問題的處理都放在 GitHub 上。我們的 Yearly/Monthly plan 都以 issue 的形式呈現(xiàn)在 Microsoft/vscode 上，而我個(gè)人正常的開發(fā)節(jié)奏是這樣的：

計(jì)劃

在上一個(gè) milestone 快結(jié)束、新的 milestone 開始的***周，和老板溝通新的 milestone 自己想做的功能。以及自己要不要休假。

Debt Week

我們把新 Milestone 的一周當(dāng)作 debt week，集中處理一些技術(shù)債，以及為一些插件做點(diǎn)微小的貢獻(xiàn)。我一般會(huì)花一點(diǎn)時(shí)間在 Vim 插件以及我自己的 Ruby 插件上。

開發(fā)

這之后就是兩到三周正常的開發(fā)。每天起床得先把自己頭上的新 issue 都 triage 一遍，遇到緊急的得先修，不然就繼續(xù)完成自己的 feature。

Inbox Tracking

我加入團(tuán)隊(duì)的時(shí)候，我們只有 1700 個(gè)左右的 issue，現(xiàn)在已經(jīng)破 4000 了(大部分都是 feature request)。GitHub Inbox 在這種情況下是無用的，我們的做法是每周會(huì)有一名同事，負(fù)責(zé) GitHub 的新 issue，assign 給合適的 owner。我已經(jīng)當(dāng)過三次 Inbox Tracker，只能用可怕來形容。每天一睜眼就是一百多個(gè) issue 要處理，一點(diǎn)都不想起床。

Endgame

我們?cè)?milestone 的***一周 endgame 會(huì)對(duì)新 feature 進(jìn)行各種花樣的測(cè)試，對(duì)這個(gè) milestone 關(guān)掉的所有 issue 進(jìn)行驗(yàn)證。全部完成后，每個(gè)成員書寫自己負(fù)責(zé)部分的 release note。*** Endgame master 會(huì)到后臺(tái)網(wǎng)站發(fā)布新的 Stable 版本。

印象深刻的事

當(dāng)之無愧就是“在空閑時(shí)，VS Code 由于渲染閃爍的光標(biāo)而占用了 13% 的 CPU”。VS Code 是基于 Electron 的，而 Electron 則基于 Chromium。這樣的話，Chromium 的鍋有時(shí)候得我們來背。

VS Code 里的編輯區(qū)域并不是 textarea ，全都是 mock 的，這也是主流做法，Ace、CodeMirror、Atom 無不例外。理由也很簡單，要實(shí)現(xiàn) Tokenize、高亮、Partial Render、Line Wrap，自己控制渲染肯定是最方便的。為了盡可能模擬 textarea，我們模擬了光標(biāo)。最開始這個(gè)光標(biāo)的跳動(dòng)，是通過 JavaScript 來控制光標(biāo)的 opacity。后來社區(qū)給我們貢獻(xiàn)了一個(gè) pull request，使用 CSS animation 來調(diào)整 opacity。實(shí)現(xiàn)上來說肯定是比 JavaScript 版本更優(yōu)雅，同時(shí)也提供了四五種不同的光標(biāo)跳動(dòng)的選項(xiàng)。

但誰知道，Chromium 對(duì)于 CSS Animation 是有巨大的坑的。比如你寫的 animation 是每秒改變一次 opacity，但是 Chromium 會(huì)根據(jù)刷新率(比如 60hz)來檢測(cè)頁面上的 animation。雖然我不知道 Chromium 做了什么，但是你可以看到每16ms，Chromium 就會(huì)吃掉一點(diǎn)你的 CPU 和 Battery

真的是一點(diǎn)辦法沒有。我們起初沒有發(fā)現(xiàn)這個(gè)問題，直到 broccoli 的作者 Jo Liss 給我們發(fā)了 issue，并且在 Twitter 上爆我們，瞬間就成了 Twitter 上大新聞。連 Miguel de Icaza 都點(diǎn)贊了，真的是……

當(dāng)時(shí)我剛吃完晚飯，但是由于這個(gè)事情在我的防區(qū)，我只好開電腦 troubleshoot。***發(fā)現(xiàn)是 Chromium 的 bug，開了兩年多了，我只好告訴 Jo Liss，這鍋我們不背，但是我們會(huì)修的。

結(jié)果之后好事者把事情捅到了 HackerNews，瞬間成了當(dāng)天大新聞，還上了 TheRegister 小報(bào)。所有人都開始討論使用 Browser 技術(shù)做桌面應(yīng)用是不是正確的選擇，撕的不亦樂乎。

你們撕的倒是開心了，我那幾天給各種老板解釋什么是跳動(dòng)的光標(biāo)，忙的跟狗一樣。好在后來 Chromium 的 PM lead Paul Irish 留言表示這是他們的 bug，算是***收官了。

有沒有什么奇葩的 issue 或者 PR?

1. 你們猜大家看到中文寫的 issue 會(huì)找誰來翻譯?
2. 有些朋友提交了 PR，根本不管你給的建議，自顧自的更新修改。這樣的 PR 根本不可能 merge，但是我們給的盡可能 polite 的建議，有些朋友真的把它們只當(dāng)成建議……
3. 再一次說到跳動(dòng)的光標(biāo)，這個(gè)始作俑者是社區(qū)的朋友，看起來也是非常 neat 的實(shí)現(xiàn)，誰知道就踩了 Chromium 的坑呢……

關(guān)于中文 issue 的問題，VS Code contribution guide 寫的是比較清楚的，請(qǐng)大家用英文提問。但是鑒于中文用戶量巨大，加之人總有英文不夠用的時(shí)候，VS Code 也會(huì)經(jīng)?？吹街形膯栴}。我有這樣一些想法：

1. 寫中文我個(gè)人覺得問題不大，畢竟 GitHub 是我們幾乎唯一的反饋渠道，不能要求用戶必須會(huì)英文。
2. 寫中文的確增加了我本人的工作量，所以能寫英文，還是盡量寫。
3. 但如果你覺得需要嚴(yán)重的 Google Translate 的幫助，我建議還是寫中文，并且 cc 我。不然可能翻譯出來***誰也看不明白，或者誤解。
4. 我老板問我，為啥中文 issue 幾乎把所有東西都寫在標(biāo)題里，然后 issue 描述留空。我真的不知道該如何回答。如果用中文寫 issue，并 cc 我，請(qǐng)保證把reproduce steps 寫好，一步一步用中文寫清楚，這總沒難度吧?
5. 如果第四步做不到，還要我解決問題，請(qǐng)考慮請(qǐng)我喝啤酒吧。

生活

大家都喜歡開源，但開源貢獻(xiàn)者大部分時(shí)候是在做義務(wù)貢獻(xiàn)。這么來看在微軟搞 VS Code 就是一件愉快的事情，畢竟有人給你付工資讓你做 open source。而且再也不用上班搞一套代碼，回家之后私下自己在 GitHub 上面逛游，搞別的項(xiàng)目，上班和下班后可以在同一塊土地上耕耘。

當(dāng)然這樣缺點(diǎn)也很明顯，就是生活和工作往往難以分開。工作是一周五天，一天八小時(shí)，但是 GiHub issue 從來都是 7*24。遇到棘手的問題的時(shí)候，很難放任不管，哪怕已經(jīng)回了家。不過也正是因?yàn)轫?xiàng)目的特殊性，我們組還是有比較好的 remote 和自由工作時(shí)間的文化的。