學生黨看過來！用 VS Code 刷 LeetCode，簡直不要太香！

來源  知乎

做者 李少俠

 

今天就爲你們分享一篇關於 VS Code 的文章：

Visual Studio Code（VS Code）近年來得到了爆炸式增加，成爲廣大開發者工具庫中的必備神器。它做爲一個開源項目，也吸引了無數第三方開發者和終端用戶，成爲頂尖開源項目之一。它在功能上作到了夠用，體驗上作到了好用，更在擁有海量插件的狀況下作到了簡潔流暢，實屬難能難得。

做爲 VS Code 用戶，同時也爲它開發插件，插件市場裏的衆多 Java 插件基本都是咱們團隊的做品，因此我在平常工做中觀察到很多 VS Code 在工程方面的亮點，下面就來逐一探討。

 

簡潔而聚焦的產品定位，貫穿始終

你知道 VS Code 的開發團隊人數只有二十出頭嗎？

難以相信吧，你們都以爲 VS Code 無所不能，如此強大的工具那麼幾我的怎麼作得出來。實際上功能豐富是個美好的錯覺，由於大部分針對特定編程語言和技術的功能都是第三方插件提供的，VS Code 的核心始終很是精簡，這很考驗產品團隊的拿捏能力：作多了，臃腫，人手也不夠；作少了，太弱，沒人用。

他們團隊選擇了專一於核心功能的開發，爲用戶提供簡潔流暢的體驗，並將該思路貫穿在產品開發的每一個環節。在我看來，這就是第一個亮點。

第一個亮點同時也是一個難點，由於 「簡潔」 說究竟是產品的 「形態」，更關鍵的實際上是前置問題 —— 產品的定位，它到底解決什麼問題。該問題若是從用戶的角度來看，能夠轉換爲如下幾個點 —— 咱們爲何須要一個新的工具？它究竟是代碼編輯器 (Editor) 仍是集成開發環境 (IDE)？讓咱們來看看項目負責人 Erich Gamma 的說法：

(視頻截圖 - Erich 闡述了 VS Code 的定位：編輯器 + 代碼理解 + 調試)

這張截圖它闡述了 VS Code 的定位：編輯器 + 代碼理解 + 調試。這是一個很是節制而平衡的選擇，專一於開發者 「最經常使用」 的功能，同時在產品的形式上力求簡潔高效。從結果來看，這個定位是至關成功的。

在這個定位的指導下，這二十多位工程師搞出了 VS Code。相對較小的功能集，使得開發者們能在代碼質量上精益求精，最終用戶們也獲得了一個性能優異的工具，這是 VS Code 從一衆編輯器中脫穎而出的重要緣由。

正由於產品定位以及團隊職責上的高度節制，團隊成員才能把時間花在這類問題上，寫出經得起考驗的代碼。

與此同時，較小的團隊也使得團隊成員作到了行爲層面的整齊劃一，這點在社區互動上體現得尤其明顯，你們能夠去 GitHub 上看他們的 Issues，超出產品定位範疇的請求和反饋基本都被婉拒或者轉交到第三方插件項目，能夠說是很專一了。

看到這裏，彷佛一切都好，但問題來了，碼農千千萬，你用 Node 我用 Go，你搞前端我弄後臺，VS Code 如何滿這些五花八門的需求呢？機智的你已經搶答了 —— 海量插件。那麼接下來咱們來深究一下 VS Code 是如何經營一個龐大的插件生態的。

C/C++的學習裙【七一二 二八四 七零五 】，不管你是小白仍是進階者，是想轉行仍是想入行均可以來了解一塊兒進步一塊兒學習！裙內有開發工具，不少乾貨和技術資料分享！

 

進程隔離的插件模型

經過插件來擴展功能的作法已是司空見慣了，但如何保證插件和原生功能同樣優秀呢？**歷史告訴咱們：不能保證。**

你們能夠參考 Eclipse，插件模型能夠說是作得很是完全了，功能層面也是無所不能，但存在幾個煩人的問題：不穩定、難用、慢，因此很多用戶轉投 IntelliJ 的懷抱。可謂成也插件，敗也插件。

問題的本質在於信息不對稱，它致使不一樣團隊寫出來的代碼，不管是思路仍是質量，都不一致。最終，用戶獲得了一個又亂又卡的產品。因此要讓插件在穩定性、速度和體驗的層面都作到和原生功能統一，只能是一個美好的願望。

來看看其餘 IDE 是怎麼作的，Visual Studio 本身搞定全部功能，而且作到優秀，讓別人無事可作，這也成就了其 「宇宙第一 IDE」 的美名；IntelliJ 與之相仿，開箱即用，插件無關緊要。這麼看起來，本身搞定全部的事情是個好辦法，但你們是否知道，Visual Studio 背後有上千人的工程團隊，顯然，這不是 VS Code 這二十幾號人能搞定的。他們選擇了讓你們來作插件，那怎麼解決 Eclipse 所遇到的問題呢？

這裏分享一個小知識 ——Eclipse 核心部分的開發者就是早期的 VS Code 團隊。嗯，因此他們沒有兩次踏入同一條河流。與 Eclipse 不一樣，VS Code 選擇了把插件關進盒子裏。

這樣作首先解決的問題就是穩定性，這個問題對於 VS Code 來講尤其重要。都知道 VS Code 基於 Electron，實質上是個 Node.js 環境，單線程，任何代碼崩了都是災難性後果。因此 VS Code 乾脆不信任任何人，把插件們放到單獨的進程裏，任你折騰，主程序妥妥的。

插件與主進程隔離

VS Code 團隊的這一決策不是沒有緣由的，正如前面提到的，團隊裏不少人實際上是 Eclipse 的舊部，天然對 Eclipse 的插件模型有深刻的思考。Eclipse 的設計目標之一就是把組件化推向極致，因此不少核心功能都是用插件的形式來實現的。遺憾的是，Eclipse 的插件運行在主進程中，任何插件性能不佳或者不穩定，都直接影響到 Eclipse，最終結果是你們抱怨 Eclipse 臃腫、慢、不穩定。VS Code 基於進程作到了物理級別的隔離，成功解決了該問題。實際上進程級別的隔離也帶出了另外一個話題，那就是界面與業務邏輯的隔離。

 

UI 渲染與業務邏輯隔離，一致的用戶體驗

「不穩定」 以後的問題是 「難用」，具體來講就是混亂的界面和流程，究其緣由就是插件之間的界面語言的 「不一致」，它致使學習曲線異常陡峭，而且在面臨問題時沒有統一的解決路徑。VS Code 的作法是根本不給插件們 「發明」 新界面的機會。

如上圖，插件們被關在 Extension Host 進程裏，而 UI 則在主進程裏，因此插件們自然無法直接在用戶界面上作手腳。

VS Code 統管全部用戶交互入口，制定交互的標準，全部用戶的操做被轉化爲各類請求發送給插件，插件能作的就是響應這些請求，專一於業務邏輯。但從始至終，插件都不能 「決定」 或者 「影響」 界面元素如何被渲染（顏色、字體等，一律不行），至於彈對話框什麼的，就更是天方夜譚了。

VS Code 對於用戶界面的把控能夠說是謹慎到變態，作過插件的人都懂的，感興趣的同窗能夠去深挖一下 TreeView 的歷史，會有更直觀的體會。乍一看，第三方開發者被卡得死死的，這樣不是限制了你們的創造力嗎？我想說這個作法跟這個團隊的背景密切相關，換一撥人頗有可能會失敗。他們之因此能成功，是由於該團隊在開發工具領域深耕多年，他們把經驗轉換爲觀點，最終落實到了 VS Code 的界面元素以及交互語言上，從結果來看，廣受歡迎。

界面和業務邏輯的完全隔離，使得全部插件有了一致的行爲，用戶就獲得了整齊劃一的體驗。不只如此，這種接口和行爲層面的一致性，最終轉化成了另外一個 「偉大」 的功能 ——Remote Development，咱們稍後討論。接下來咱們要聊的是 VS Code 另外一個創舉 ——Language Server Protocol。

LSP—— 基於文本的協議

前文提到了 VS Code 定位中的兩個特點：代碼理解和調試，絕大部分都由第三方插件來實現，中間的橋樑就是兩大協議 ——Language Server Protocol (LSP) 和 Debug Adapter Protocol (DAP)。二者從設計的角度來看高度類似，咱們着重看一下最火的 LSP。首先，爲何須要 LSP？

全棧開發早已成爲這個時代的主流，軟件從業者們也愈來愈不被某個特定的語言或者技術所侷限，這也對咱們手裏的金剛鑽提出了新的挑戰。

舉個栗子，我用 TypeScript 和 Node.js 作前端，同時用 Java 寫後臺，偶爾也用 Python 作一些數據分析，那麼我頗有可能須要若干工具的組合，這樣作的問題就在於須要在工具間頻繁切換，不管從系統資源消耗和用戶體驗的角度來看，都是低效的。

那麼有沒有一種工具能在同一個工做區裏把三個語言都搞定呢？沒錯，就是 VS Code—— 支持多語言的開發環境，而多語言支持的基礎就是 Language Server Protocol (LSP)。

該協議在短短几年內取得了空前的成功，到目前爲止，已經有來自微軟等大廠以及社區的一百個實現，基本覆蓋了全部主流編程語言。同時，它也被其餘開發工具所採納，好比 Atom、Vim、Sublime、Emacs、Visual Studio 和 Eclipse，從另外一個角度證實了它的優秀。

更難能難得的是，該協議還作到了輕量和快速，能夠說是 VS Code 的殺手級特性了，同時也是微軟最重要的 IP 之一。。。哇塞，又強大又輕巧，怎麼看都是個騙局啊，那咱們就來看看它到底怎麼作到的。

先劃重點：一、節制的設計 二、合理的抽象 二、周全的細節。

先來講說設計 (Design)，大而全是很常見的問題。若是讓我來設計這麼一個用來支持全部編程語言的東西，第一反應極可能是搞個涵蓋全部語言特性的超集。

微軟就有過這樣的嘗試，好比 Roslyn—— 一個語言中立的編譯器，C# 和 VB.NET 的編譯器都是基於它作的。你們都知道 C# 在語言特性層面是很是豐富的，Roslyn 能撐起 C# 足以說明它的強大。那麼問題來了，爲啥它沒有在社區獲得普遍應用呢？我想根本緣由是 「強大」 所帶來的反作用：複雜、主觀 (Opinionated)。光是語法樹就已經很複雜了，其餘各類特性以及他們之間的關係更是讓人望而卻步，這樣一個龐然大物，普通開發者是不會輕易去碰的。

相較之下，LSP 顯然把小巧做爲設計目標之一，它選擇作最小子集，貫徹了團隊一向節制的做風。它關心的是用戶在編輯代碼時最常常處理的物理實體（好比文件、目錄）和狀態（光標位置）。它根本沒有試圖去理解語言的特性，編譯也不是它所關心的問題，因此天然不會涉及語法樹一類的複雜概念。

它也不是一步到位的，而是隨着 VS Code 功能的迭代而逐步發展的。因此它自誕生至今依然保持着小巧的身材，易懂，實現門檻也很低，迅速在社區獲得了普遍的支持，各類語言的 Language Server (LS) 遍地開花。

小歸小，功能可不能少，因此抽象就很是關鍵了。LSP 最重要的概念是動做和位置，LSP 的大部分請求都是在表達」 在指定位置執行規定動做 「。

舉個栗子，用戶把鼠標懸停在某個類名上方，查看相關的定義和文檔。這時 VS Code 會發送一個 'textDocument/hover' 請求給 LS，這個請求裏最關鍵的信息就是當前的文檔和光標的位置。LS 收到請求以後，通過一系列內部計算（識別出光標位置所對應的符號，並找出相關文檔），找出相關的信息，而後發回給 VS Code 顯示給用戶看。這樣一來一回的交互，在 LSP 裏被抽象成請求 (Request) 和回覆 (Response)，LSP 同時也規定了它們的規格 (Schema)。在開發者看來，概念很是少，交互形式也很簡單，實現起來很是輕鬆。

看到這裏，你們應該對 LSP 有了更進一步的理解，它本質上是膠水，把 VS Code 和各類語言的 LS 粘在一塊兒。但它不是普通的膠水，而是很是有品位的膠水，這品位就體如今細節上。

首先這是一個基於文本的協議，文本下降了理解和調試的難度。參考 HTTP 和 REST 的成功，很難想象若是這是一個二進制協議會是什麼局面，甚至一樣是文本協議的 SOAP 也早已做古，足以說明 「簡單」 在打造開發者生態裏的重要性。

其次這是一個基於 JSON 的協議，JSON 能夠說是最易讀的結構化數據格式了，你們看看各個代碼倉庫裏的配置文件都是啥格式就知道這是個多麼正確的決定了，如今還有人在新項目裏用 XML 嗎？又一次 ——「簡單」。

再次，這是一個基於 JSONRPC 的協議，因爲 JSON 的流行，各大語言都對它有極好的支持，因此開發者根本不須要處理序列化、反序列化一類的問題，這是實現層面的 「簡單」。

從這些細節能夠看出，VS Code 團隊對當今技術趨勢的把握是至關精準的，他們決策充分考慮到了 「簡單」，緊緊抓住了社區開發者的心。因此重要的事情說三遍：

在作設計的時候必定要傾向於簡單。

在作設計的時候必定要傾向於簡單。

在作設計的時候必定要傾向於簡單。

 

集大成的 Remote Development

今年五月，VS Code 發佈了 Remote Development (VSCRD)，有了它，咱們能夠在遠程環境（好比虛機、容器）裏開一個 VS Code 工做區，而後用本地的 VS Code 連上去工做，下圖說明了它的運行模式：

VSCRD 從本質上改善了遠程開發的體驗，與經常使用的遠程桌面共享相比，具體改進以下：

響應迅速：VSCRD 全部的交互都在本地 UI 內完成，響應迅速；遠程桌面因爲傳輸的是截屏畫面，數據往返延遲很大，卡頓是常態

沿用本地設置：VSCRD 的 UI 運行在本地，聽從全部本地設置，因此你依然可使用本身所習慣的快捷鍵、佈局、字體，避免了工做效率層面的開銷

數據傳輸開銷小：遠程桌面傳輸的是視頻數據，而 VS Code 傳輸是操做請求和響應，開銷與命令行相仿，卡頓的狀況進一步改善

第三方插件可用：在遠程工做區裏，不只 VS Code 的原生功能可用，全部第三方插件的功能依然可用；遠程桌面的話，你得本身一個個裝好

遠程文件系統可用：遠程文件系統被完整映射到本地，這個二者差很少

那麼 VSCRD 作了什麼神奇的操做可以實現以上效果呢？來看看它的架構圖：

其實答案都在前文有所說起：

進程級別隔離的插件模型

Extension Host（也就是圖中的 VS Code Server）與主程序作到了物理級別的分離，那麼把 Extension Host 在遠程或者本地跑沒有本質的區別

UI 渲染與插件邏輯隔離，整齊劃一的插件行爲

全部的插件的 UI 都由 VS Code 統一渲染，因此插件裏面只有純業務邏輯，行爲高度統一，跑在哪裏都沒區別

高效的協議 LSP

VS Code 的兩大協議 LSP、DAP 都很是精簡，自然適合網絡延遲高的狀況，用在遠程開發上再適合不過

VS Code 團隊在架構上的決策無疑是很是有前瞻性的，與此同時，他們對細節的把握也是無可挑剔。正由於有了如此紮實的工程基礎，VSCRD 這樣的功能才得以誕生，因此我認爲這是集大成的做品。

尚未嘗試過 VSCRD 的同窗，這裏再安利一下，它在如下場景中很是有用：

開發環境配置起來很繁瑣，好比物聯網開發，須要本身安裝和配置各類工具和插件。在 VSCRD 裏，一個遠程工做區的模板便可搞定，如需安裝額外的工具，也就是改改 Dockerfile 的事情，很是簡單。在這裏能夠找到經常使用的編程語言和場景的模板。

本地機器太弱，某些開發搞不了，好比機器學習，海量數據及和計算需求須要很是好的機器。在 VSCRD 裏，能夠直接操做遠程文件系統，使用遠程計算資源。

最後

VS Code 像一顆耀眼的星星，吸引着成千上萬開發者爲其添磚加瓦。從 VS Code 的成功中，咱們看到了好的設計和工程實踐能創造多少奇蹟。放眼軟件產業，各個層面的模式不斷被刷新，讓人激動之餘，也要求從業者不斷提升技能水平。從我的學習的角度來看，瞭解這些模式誕生的來龍去脈，理解工程實踐中的決策過程是很是有利於提升工程能力的。

 

若是你也想要學習編程，接受全面系統的指導。這裏有一個學習基地推薦給你。不管是小白仍是進階者，在這裏都能得到成長。進羣便可聯繫管理員領取新手學習資料包，點我進入學習基地