本文來自於知乎上《維護一個大型開源項目是怎樣的體驗？》中的 rebomix 的回答。本文作者 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 有諸多誤解，我先來一一解答
「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 自己想做的功能。以及自己要不要休假。
我們把新 Milestone 的一周當作 debt week，集中處理一些技術債，以及為一些插件做點微小的貢獻。我一般會花一點時間在 Vim 插件以及我自己的 Ruby 插件上。
這之後就是兩到三周正常的開發。每天起床得先把自己頭上的新 issue 都 triage 一遍，遇到緊急的得先修，不然就繼續完成自己的 feature。
我加入團隊的時候，我們只有 1700 個左右的 issue，現在已經破 4000 了（大部分都是 feature request）。GitHub Inbox 在這種情況下是無用的，我們的做法是每周會有一名同事，負責 GitHub 的新 issue，assign 給合適的 owner。我已經當過三次 Inbox Tracker，只能用可怕來形容。每天一睜眼就是一百多個 issue 要處理，一點都不想起床。
我們在 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，根本不管你給的建議，自顧自的更新修改。這樣的 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 和自由工作時間的文化的。
（題圖：Pixabay，CC0）
轉載自：知乎，作者： Daniel Stori，via：Linux 中國