在編程中，VS Code 作為我的主 IDE 長達 5 年之久。在這個時間點上我決定換掉它，這可能會令人無法理解。本文我將和大家分享我做這個決定的原因。

背景

愿意的話你也可以說我是瘋子。你可能會認為，一個用了 VS Code 長達 5 年的人，一定是瘋了才會想在此時換掉它。的確，在我接觸 JetBrains 生態(tài)之前，也是這么認為的。我甚至愿用我的性命證明 VS Code 是目前市場上最好的 IDE，它就如同 PC 行業(yè)中的蘋果 M1 芯片電腦一樣。但請允許我先介紹下事情的背景。

我目前在 Blankly 工作，該公司主提供對沖基金云服務(wù)。在我們提供的云服務(wù)上，人們只需要幾分鐘即可創(chuàng)建自己的交易算法。我的一個同事 Emerson，他是 JetBrains 生態(tài)的鐵桿粉絲。在一次日站會上，他為了說服我們?nèi)ピ囈幌?JetBrains 的生態(tài)，甚至不惜延長了會議時間。我為了讓會議對于這件事的討論早點結(jié)束（這樣站立會也能早點結(jié)束），我勉強同意了。然而誰承想，現(xiàn)在我居然在這里寫了一篇關(guān)于是什么最終說服我愿意放棄一直陪伴我的 IDE 的文章。因此，如果你正好處在糾結(jié)選擇用什么 IDE 且完全沒有考慮 JetBrains 想法，或你對我為什么放棄 VS Code 感興趣的話，那么，這篇文章非常適合你繼續(xù)讀完。

本文是根據(jù)我使用 VS Code 和 JetBrains 的一些切身體會，將從 5 個方面對它們進行的對比分析。并且闡述了一些使用場景中 JetBrains 優(yōu)勢明顯的原因。

代碼檢查和重構(gòu)

VS Code：快、簡單、支撐多語言

首先，任何編程語言在 VS Code 中都可以簡單且快速地啟動和運行，所以大家也會稱它為“編輯器”。因此，VS Code 對于像我這樣的全棧工程師來說是最佳選擇。無論你是需要頻繁在 Python 和 JavaScript 之間切換，還是需要增加一個基于 NextJS 開發(fā)的 React App，還是需要在 Ralis 系統(tǒng)上配置 Ruby 環(huán)境，這些能力 VS Code 都能很好地支持，并為這些開發(fā)語言提供了包括 lingting 在內(nèi)的一系列開箱即用的功能。即使碰到某個功能沒有，那也只需要在其插件市場上搜索一個，找一個具備此功能的插件進行安裝即可。

其次，由于有了諸如 Github Copilot，AI-based linting，auto imports 等一系列插件的支撐，VS Code 具備了強大的 linting 能力。在 VS Code 中，無論你什么時候想要什么功能，配置起來都非常容易。很多時候，只是需要敲個結(jié)束符，VS Code 就會將你想要的內(nèi)容提示出來。不過有些時候，人們也會因為這種 linting 能力的失效而崩潰。實際上，我時常陷入試圖弄清楚為什么一個標準的 linting 不能工作的困境中。不管是由于我使用 Anaconda 安裝的多 python 環(huán)境導(dǎo)致，還是由于少了安裝包導(dǎo)致，但很多時候我都無法直接得到答案。此外，VS Code 針對 JavaScript 語言的 linting 能力也非常強大，不過它不會對 JavaScript 進行深入的類型檢查，慶幸的是，我們可以通過 TypeScript 來解決這個問題。

如圖所示，由于我忘記切換 VS Code 中的 Python 環(huán)境，所以即使我本地已經(jīng)通過 pip 安裝了相關(guān)依賴包，但 VS Code 的 linting 功能依然提示包未找到。

最后，作為一個編輯器，VS Code 在代碼重構(gòu)上表現(xiàn)的確非常出色。它在諸如變量重命名、文件移動和引用自動修改等基礎(chǔ)的重構(gòu)功能上表現(xiàn)得非常棒。但在諸如函數(shù)移動、參數(shù)重命名、代碼抽取等更高級別的重構(gòu)功能方面，它就顯得有些能力不夠了。不過，幸運的是，僅僅一些基礎(chǔ)的重構(gòu)功能就足以滿足我們?nèi)粘４蟛糠种貥?gòu)需求。在我使用 VS Code 的五年中，它滿足了我遇到的大多數(shù)重構(gòu)場景。

JetBrains：標準、專業(yè)、支撐強大

首先，JetBrains 是一個包含了很多不合理初始設(shè)置的強大 IDE。在我第一次接觸它的時候，為了讓代碼顯示的比較優(yōu)雅，不得不在設(shè)置上大費周章。不過，在兩個為不同使用場景設(shè)計的 IDE 之間做切換，付出一些學(xué)習(xí)的時間成本是不可避免的。如果我的一個 POST 請求突然出問題了，我就得打開 PyCharm，看看是不是我后端 API 服務(wù)出問題 了；如果在推薦類項目中，我突然對最佳推薦算法有了新的優(yōu)化思路，我就需要打開 CLion。不過，由于有了智能識別，在打開不同 IDE 的時候，我只需要花點時間練習(xí)下將 code . 切換到諸如 webstorm . 和 pycharm. 等其他腳本。

其次，JetBrains 的引擎性能強大。當我將 IDE 都替換為 JetBrains 之后，它強大的引擎性能讓我印象深刻。當我在編輯器中看到一些紅線警告的時候，我只需要使用快捷鍵 comman+p 將當前窗口重新加載一次，這些紅線警告就會消失，或者會給出一些有用的提示信息。這種簡單和快速響應(yīng)的代碼檢查，讓我在編程時心情愉快。

如上圖，只需要一個快捷鍵，就能看到所有引用的地方。

最后，在重構(gòu)能力上，JetBrains 功能強大，這也是它真正吸引我的地方。就在上周，在為公司平臺構(gòu)建最后的內(nèi)測版本期間，為了讓組件未來具備更強的擴展性，我重構(gòu)和新增了一些組件。期間，我大概移動了 200 個組件，在項目編譯的時候，沒有一次編譯異常是由引用錯誤、非法或未定義組件引起的。然后，在 VS Code 中，我在一個數(shù)據(jù)結(jié)構(gòu)類的項目中，僅僅重新組織了兩個文件就破壞了整個 cpp 代碼。為此，我不得不手動修正一些組件導(dǎo)入和函數(shù)引用才能使項目正常運行。另外，JetBrains 為了確保我們能有足夠多的重構(gòu)工具，它還提供了諸如安全刪除、全局重命名等多種外部工具。

通過 JetBrains 可以很清楚的看到將被重構(gòu)或重命名的變量的的全部調(diào)用以及上下文情況圖

JetBrains 生態(tài) IDE 提供的閱讀幫助功能

能力對比

總的來說，我認為在代碼檢查和代碼重構(gòu)上，VS Code 和 JetBrains 兩者能力接近。兩者都是通過諸如自動代碼檢查、代碼格式化、主題定制等功能，幫助人們更好地進行代碼調(diào)試和顯示。不過，JetBrains 具備優(yōu)秀的 linting 引擎和無副作用的重構(gòu)能力，因此，如果代碼分解和重構(gòu)對你和你的工作流程很重要，那么，我推薦你選擇 JetBrains。

調(diào)試

VS Code：幾乎可以調(diào)試一切

VS Code 超強的調(diào)試能力，歸功于其強大的插件支撐。你每次點擊 VS Code 左邊的運行按鈕，VS Code 都會生成一個.vscode 的文件夾，此文件中存放了一個 settings.json 文件，這個文件包含了調(diào)試相關(guān)的全部配置。對于諸如 Python、JavaScript 等大多數(shù)語言來說，使用 VS Code 作為其調(diào)試工具是非常方便的。甚至，如果你的環(huán)境配置正確無誤的話，通過直接點擊調(diào)試按鈕來進行調(diào)試會更加便捷。此外，即使是通過修改 settings.json 文件中的配置來改變你當前的調(diào)試內(nèi)容也是非常簡單的。不過，如果你用了特定的構(gòu)建方式或特定平臺語言（如：C/C++ 語言），由于需要設(shè)置 gcc 和 clang，因而會大幅增加在 VS Code 中進行調(diào)試的難度和復(fù)雜度，同時設(shè)置這類文件的調(diào)試配置也會比較費時費力。為了減少這種時間的投入，我嘗試將其他項目的 setting.json 文件拷貝到當前項目中，但是效果不理想，我花了很多天的調(diào)整，才使當前的項目正常運行。在我的大學(xué)（密歇根大學(xué)安娜堡分校），為了減少大家在調(diào)試配置上耗費的精力，他們就維護了一個通用的 settings.json 文件提供給所有人使用。但是即使這樣，人們還是不得不花時間去調(diào)整 settings.json 文件。

上圖顯示了一個為了在 MacOS 上進行 C/C++ 程序調(diào)試所需要的最簡配置

在實際進行調(diào)試的過程中，VS Code 在調(diào)試控制臺中可以很好地進行調(diào)試斷點設(shè)置、識別變量和添加變量觀察者。不過，如果這些功能可以直接在代碼面板而不是側(cè)面板上進行設(shè)置，那就好更好了。

慶幸的是，插件和多語言支持是 VS Code 的最大優(yōu)勢，這使得人們可以在幾分鐘，甚至幾秒鐘內(nèi)就完成代碼調(diào)試的設(shè)置工作。對一些簡單的調(diào)試場景，VS Code 的調(diào)試能力表現(xiàn)得非常棒。然而當需要調(diào)試特殊語言的時候，VS Code 的調(diào)試能力往往會難以勝任。同時，我還發(fā)現(xiàn)當程序需要用到更大的堆內(nèi)存的時候，VS Code 的調(diào)試器會一直卡到崩潰。

JetBrains：一個調(diào)試怪物

相對于 VS Code，JetBrains 在調(diào)試方面功能更強。由于 JetBrains 所有系列的 IDE 都是基于配置運行的，因此你可以通過點擊調(diào)試按鈕開始任何一次程序調(diào)試。如果想設(shè)置全局的調(diào)試斷點，只需要在編輯器的行號處按下空格鍵即可，此功能極大得提高了程序調(diào)試的體驗。此外，JetBrains 系列的 IDE 在整個調(diào)試過程中還有很多其他的功能亮點，例如：當進入調(diào)試環(huán)節(jié)，作用域內(nèi)的所有變量的定義，對于定義者來說都是可見的。這讓我們可以很方面的觀察當前變量值的變化情況。幾天前用 Pycharm 調(diào)試程序的過程令我印象深刻。當我在 Pycharm 中運行調(diào)試并試圖查看數(shù)據(jù)幀的值時，只要點擊數(shù)據(jù)幀變量并按下 view 作為數(shù)據(jù)幀，Pycharm 就會在 SciView 中打開數(shù)據(jù)幀，并顯示所有數(shù)據(jù)幀值和列標題:

上圖顯示的是運行調(diào)試且變量值變化的監(jiān)控

如上面截圖所示，底部的窗口中顯示了作用域內(nèi)的全部值。history_and_returns 的下拉菜單中顯示了字典對象的所有屬性值以及嵌套在該字典對象中的數(shù)據(jù)幀。右邊的面板中，則和 SciView 一樣，顯示了已經(jīng)嵌套在字典中的數(shù)據(jù)幀。在不設(shè)置任何打印語句或堆棧跟蹤的情況下，就能如此深入了解代碼，對于開發(fā)人員來說是非常有用的。試想一下，當所有變量的賦值都被編輯器顯示在其旁邊時，我們可以很容易找到循環(huán)中的邏輯錯誤、修復(fù)因為索引導(dǎo)致的故障甚至做一些更加深入的邏輯推理。

與其他 IDE 的調(diào)試器一樣，JetBrains 調(diào)試器同樣提供了諸如下一行、進入某個函數(shù)等步進的調(diào)試功能。另外，JetBrains 的 Run to Cursor 是一個非常好用的功能，它允許人們通過放置鼠標，就可以如同設(shè)置斷點一樣，起到調(diào)試斷點的效果。這種可以隨時隨地設(shè)置斷點且立即生效的功能，完全我調(diào)試代碼的方式并且大幅加速了我編程的速度。

能力對比

程序調(diào)試是開發(fā)人員每天最常做的事情之一。因此我認為，當開發(fā)人員選擇 IDE 的時候，IDE 是否擁有一個好的調(diào)試器是必須考慮的因素。VS Code 和 JetBrains 都提供了非?？煽康恼{(diào)試器，但是我必須說在這方面 JetBrains 比 VS Code 略勝一籌。因為，JetBrains 可以直接在變量聲明的邊上直接顯示變量值，這使得跟蹤大量變量的時候會比較容易管理。此外，JetBrains 的調(diào)試器更強大、更穩(wěn)定，它不像 VS Code 調(diào)試器那樣需要做復(fù)雜的設(shè)置。因此，結(jié)合這些因素，JetBrains 的調(diào)試能幫助我們節(jié)約更多的調(diào)試時間，這也使得 JetBrains 更具吸引力。

集成 Git

VS Code：內(nèi)置了一個強大的源碼控制管理

需要團隊協(xié)作或在乎代碼安全的人都知道 Git 在他們工作流中的重要性。對于任何現(xiàn)代編輯器來說，基于 Git 的版本控制都是不可或缺的功能。VS Code 和 Git 的集成做的非常好，當你打開一個工作目錄的時候，它會自動檢測這是否為一個 Git 倉庫。如果是，那么它就會立即提供諸如 push、pull、commit 等許多固有的 Git 命令。

在 VS Code 的 Git 面板中，人們可以清楚的看到哪些些文件做了修改，且輕松完成同步。同時，在面板中，也可以創(chuàng)建分支、克隆倉庫。VS Code 總能清楚的告訴你該怎么做，這也是我喜歡它的一個原因。當它檢測到了文件修改，就會立即提示你提交，并且在提交的時候會提示你需呀附帶上提交說明。此外，在提交的時候，它還會對本地分支和遠程分支進行檢測和同步。與此同時，它還提供了非常穩(wěn)定的變基功能。

在行內(nèi)可以清楚的看到哪里需要做沖突合并

合理處理沖突合并的能力，是 VS Code 的一大優(yōu)勢。借助 VS Code 自動提供的沖突解決方案，我可以通過點擊按鈕來選擇使用當前更改還是選擇使用傳入的更改。這種解決合并沖突的方式，為我節(jié)約了很多時間。

JetBrains：再也不需要使用命令行來做源碼管理

在全面切換到 JetBrains 之后，我?guī)缀鯖]有碰過我的終端命令行。JetBrains 提供了包括提交、沖突解決、分支切換和分支對比等在內(nèi)的源碼管理等整體功能。從我的體驗來看，JetBrains 在源代碼控制上比 VS Code 的要好得多。下面我羅列一些使用體驗的截圖：

在兩個分支之間對比某個文件

內(nèi)置的分支詳情展示

詳細的 git 日志

能力對比

在 Git 集成上，JetBrains 和 VS Code 都提供了完整且相同的功能。無論你選擇哪款 IDE，在源碼管理上都有足夠的功能支撐。因此這方面不能作為選擇 IDE 的考慮因素，只是個人喜好不同而已。例如，在解決合并沖突的時候，相對于 VS Code 將沖突文件堆在一個文件中顯示的方式，我更喜歡 JetBrains 將沖突文件分開顯示的方式。

擴展性

VS Code：豐富的擴展性

VS Code 是最具擴展性的編輯器之一，而且集成能力和可擴展性是它的核心功能。在眾多擴展能力中，Python 擴展、遠程開發(fā)擴展以及一些智能感知驅(qū)動的擴展是目前最熱門的。此外，VS Code 也有一些很酷的功能，例如通過 Prettier 進行代碼格式化，通過圖標和代碼編輯器主題進行主題定制等。VS Code 提供的每個事項或功能特性都是完全可擴展的，同時擴展的本身也可能是增強擴展能力的過程。

對遠程 docker 容器的支持，是我最喜歡的一個 VS Code 擴展能力。通過此功能，用戶可以在 VS Code 中在 docker 容器內(nèi)部進行遠程編程。如果你本地或遠程環(huán)境安裝了 docker，那么在 VS Code 中你就可以輕松的運行你的代碼以及完成所有之前需要在 docker 中才能完成的事情。想要一些更有趣的東西？通過 SSH 進行遠程開發(fā)怎么樣？微軟開發(fā)的擴展插件就允許人們在 VS Code 中通過遠程 SSH 進入到服務(wù)端開發(fā)環(huán)境，如同本地一樣進行遠程開發(fā)。在 VS Code 中想要集成這些功能，只需要簡單點擊安裝一下，就可以成功運行，所有的這些功能，成就了 VS Code 的偉大。

JetBrains：集成生態(tài)

對于 JetBrains 來說，可擴展性并不是它需要突出的一個點，因為你會發(fā)現(xiàn)絕大部分你需要的功能都會隨著的 IDE 版本的發(fā)布而發(fā)布。為某種語言安裝一款強大的 IDE 的好處是，當我們需要某些新功能的時候可能只需要升級下 IDE 版本就擁有了，而無需去擴展市場進行尋找。

例如，JetBrains 針對 docker 提供了強大內(nèi)置支撐。僅通過指定一個諸如 Dockerfile 的配置類型文件，所有的 JetBrains 的 IDE 都會通過一個易用的 GUI 提供對所有參數(shù)、名稱、標簽、端口以及環(huán)境變量的完整控制。在運行的時候，IDE 通過集成 docker，為你提供 docker 的構(gòu)建日志、運行日志、環(huán)境變量以及可視化的集成配置信息：

在集成 FastAPI、Flask、shell 等第三方能力上，JetBrains 提供了和集成 docker 一樣的能力。

此外，JetBrains IDE 也有一個豐富的插件生態(tài)系統(tǒng)。例如，我可以為支持 Verilog 和 Matlab 分別安裝特定的插件。不過有趣的是，這些輕量級的插件，居然比本地安裝的 Matlab 和 Quartus（Verilog 的開發(fā)環(huán)境）環(huán)境提供了更好的編程體驗。

能力對比

毫無疑問，兩者在擴展或插件上都有廣泛的社區(qū)和市場的支撐。兩款 IDE 在功能上各有千秋。兩款編輯器之間互缺的功能，你可能希望他們各自豐富起來。不過，VS Code 的社區(qū)稍微大些，因而擁有更多的擴展和一些諸如遠程容器擴展之類的能力，這樣使我們迭代的速度更快。因此，如果你日常工作中對諸如 Docker 的定制擴展有比較多的需求，那么 VS Code 可以說是你的專屬 IDE 了。

協(xié)作能力

VS Code：基于插件實現(xiàn)實時共享

雖然 VS Code 自身沒有內(nèi)置的實時共享功能，但微軟為其開發(fā)了一個具備此功能的插件。除此之外，現(xiàn)在，人們甚至可以直接通過使用瀏覽器訪問 vscode.dev 進行實時共享。這種需求實現(xiàn)的多樣性，正是 VS Code 如此受歡迎的原因。只要你有良好的網(wǎng)絡(luò)環(huán)境，實時共享的體驗就會很好。在實時共享的過程中，人們可以如同面對面一樣的進行結(jié)伴協(xié)同工作。同時，在源碼控制上，VS Code 還會時時追蹤那些幫助作者提交代碼的人。這些讓我們看到了在 VS Code 中開啟實時共享功能是如此的簡單。因此，在我看來，VS Code 在實時共享功能上比市面上任何其他的 IDE 和編輯器都要優(yōu)秀。

不過在使用 VS Code 的實時共享功能，還是有些需要注意的地方。下面我舉一個在 Vue.js 項目中使用實時共享功能的例子。在實時共享 Vue 代碼時，包括 Vetur（Vetur 是 Vue 可視化的重要插件）在內(nèi)的部分插件是不會被共享的。這種缺陷，時常會令人們陷入困境和煩躁中。不過還好，這樣的缺陷，只會影響到某些特定的用戶（如本例中，就只會影響 Vue 的用戶）。另外，最令我厭恨的是，在實時共享中，撤銷功能居然是綁定到了機器上而不是當前用戶上，這導(dǎo)致我的撤銷功能會在本地和遠程之間發(fā)生混亂。

JetBrains：安全、分布式

所有 JetBrains 生態(tài)的 IDE 在代碼共享和在線協(xié)同的功能上，都提供了非常多的設(shè)置項。這些設(shè)置項根據(jù)不同的安全等級而有所不同。我最近發(fā)現(xiàn)一個令人印象深刻的能力是，通過 projector（投影）技術(shù)，可以在 docker 容器中運行任何 JetBrains 的 IDE，這使得我可以連接到一個基于云服務(wù)運行的 JetBrains 的 IDE 上，同時在瀏覽器中使用完整的 JetBrains 的 IDE 的功能進行編碼。因此現(xiàn)在，我可以僅憑一個密碼，通過使用一個 headless 的服務(wù)，就可以隨時隨地的安全的進行編碼。這還只是 JetBrains 眾多共享配置中的一個。

在所有的 JetBrains 的 IDE 中，通過 Code With Me 進行實時共享是主流方式。這種方式使得你可以在本地 IDE 中直接查看其他人的項目。與此同時，你還可以如同使用本地開發(fā)環(huán)境一樣，使用其他人的開發(fā)環(huán)境運行項目。一個印象深刻的場景是，我的一個團隊成員，遇到了一個 python 的問題，他通過 Code With Me 向我發(fā)起了一個代碼實時共享，我通過此共享，在我自己的 IDE 中，如同本地一樣的使用他的配置，經(jīng)過代碼的調(diào)試，我很輕松的幫助他解決了這個問題。

各種不同優(yōu)秀的共享 IDE 的方案，在嘗試提高安全、協(xié)作能力或分布式團隊如何協(xié)同工作上的表現(xiàn)是令人驚訝的。

能力對比

如果是在兩年前，我可能會認為實時共享功能無足輕重。事實上，兩年前我甚至都不知道 IDE 中有代碼協(xié)同的功能。因為在兩年前，當我們需要協(xié)同工作的時候，根本不會通過 IDE 發(fā)起遠程協(xié)作，而是直接坐到同一臺機器前。但是現(xiàn)在受到新冠疫情的影響，這種面對面的協(xié)同工作已經(jīng)是種奢望且變得極為困難。正因如此，兩款 IDE 在實時代碼共享上都做了強力的支撐。但是，由于 VS Code 中撤銷功能的問題，因此我極力推薦 JetBrains。而且，視頻和音頻通話的支持和用戶間 Git 的追蹤能力都是同樣重要。

總結(jié)

除了上面列出的 5 方面對比之外，我也知道，相對于 VS Code 的完全免費，JetBrains 對于非學(xué)生的用戶的需要收取一定的費用，這或許也是導(dǎo)致很多人不考慮 JetBrains 的原因之一。但是，對我而言，在使用 JetBrains 生態(tài)的幾個月的時間里，它給我?guī)砹朔浅２诲e的體驗。而且，我已經(jīng)迫不及待的希望在工作中更多的去使用它們了。因此，我希望即使 JetBrains 需要花費一些費用，你也可以考慮一下它。