維護 VS Code 開源項目背後的那些事情

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

項目

visual studio code 的目标是做一個 lightweight editor，通過的擴充 api，讓使用者在 vs code 中達到和 ide 中接近的開發體驗（效率）。

不過很多群衆對 vs code 有諸多誤解，我先來一一解答

“vs code 師出 vs，是 vs 找了一群人來重寫的，複用了很多 vs 的代碼，等等“。

很抱歉，并不是這樣，半毛錢關系也沒有。vs code 的核心代碼，也就是 microsoft/monaco-editor是 erich gamma 2011 年加入微軟後，招聘的一支“全新”的隊伍進行開發的。monaco editor 從一開始就是一個基于浏覽器的編輯器，早期一直服務于各個微軟系統中（比如 visual studio online，onedrive online）。招聘的這支隊伍對于 erich 來說并不是新的，因為大部分成員都是其原先 ibm 的老部下，其中幾位大爺跟着 erich 撸了二十多年代碼了。

"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？

你們猜大家看到中文寫的 issue 會找誰來翻譯？

有些朋友送出了 pr，根本不管你給的建議，自顧自的更新修改。這樣的 pr 根本不可能 merge，但是我們給的盡可能 polite 的建議，有些朋友真的把它們隻當成建議……

再一次說到跳動的光标，這個始作俑者是社群的朋友，看起來也是非常 neat 的實作，誰知道就踩了 chromium 的坑呢……

關于中文 issue 的問題，vs code contribution guide 寫的是比較清楚的，請大家用英文提問。但是鑒于中文使用者量巨大，加之人總有英文不夠用的時候，vs code 也會經常看到中文問題。我有這樣一些想法：

寫中文我個人覺得問題不大，畢竟 github 是我們幾乎唯一的回報管道，不能要求使用者必須會英文。

寫中文的确增加了我本人的工作量，是以能寫英文，還是盡量寫。

但如果你覺得需要嚴重的 google translate 的幫助，我建議還是寫中文，并且 cc 我。不然可能翻譯出來最後誰也看不明白，或者誤解。

我老闆問我，為啥中文 issue 幾乎把所有東西都寫在标題裡，然後 issue 描述留白。我真的不知道該如何回答。如果用中文寫 issue，并 cc 我，請保證把reproduce steps 寫好，一步一步用中文寫清楚，這總沒難度吧？

如果第四步做不到，還要我解決問題，請考慮請我喝啤酒吧。

生活

大家都喜歡開源，但開源貢獻者大部分時候是在做義務貢獻。這麼來看在微軟搞 vs code 就是一件愉快的事情，畢竟有人給你付工資讓你做 open source。而且再也不用上班搞一套代碼，回家之後私下自己在 github 上面逛遊，搞别的項目，上班和下班後可以在同一塊土地上耕耘。

當然這樣缺點也很明顯，就是生活和工作往往難以分開。工作是一周五天，一天八小時，但是 gihub issue 從來都是 7*24。遇到棘手的問題的時候，很難放任不管，哪怕已經回了家。不過也正是因為項目的特殊性，我們組還是有比較好的 remote 和自由工作時間的文化的。