使用 VS Code 五年後，我決定換回 Pychar

作者 | Jeremy Liu

譯者 | 許學文 @InfoQ

本文最初發佈於 Blankly 上，經原作者授權由 InfoQ 中文站翻譯並分享。

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

背    景

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

我目前在 Blankly 工作，該公司主提供對沖基金雲服務。在我們提供的雲服務上，人們只需要幾分鐘即可創建自己的交易算法。我的一個同事 Emerson，他是 JetBrains 生態的鐵桿粉絲。在一次日站會上，他爲了說服我們去試一下 JetBrains 的生態，甚至不惜延長了會議時間。我爲了讓會議對於這件事的討論早點結束（這樣站立會也能早點結束），我勉強同意了。然而誰承想，現在我居然在這裏寫了一篇關於是什麼最終說服我願意放棄一直陪伴我的 IDE 的文章。因此，如果你正好處在糾結選擇用什麼 IDE 且完全沒有考慮 JetBrains 想法，或你對我爲什麼放棄 VS Code 感興趣的話，那麼，這篇文章非常適合你繼續讀完。

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

代碼檢查和重構

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

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

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

如圖所示，由於我忘記切換 VS Code 中的 Python 環境，所以即使我本地已經通過 pip 安裝了相關依賴包，但 VS Code 的 linting 功能依然提示包未找到。

最後，作爲一個編輯器，VS Code 在代碼重構上表現的確非常出色。它在諸如變量重命名、文件移動和引用自動修改等基礎的重構功能上表現得非常棒。但在諸如函數移動、參數重命名、代碼抽取等更高級別的重構功能方面，它就顯得有些能力不夠了。不過，幸運的是，僅僅一些基礎的重構功能就足以滿足我們日常大部分重構需求。在我使用 VS Code 的五年中，它滿足了我遇到的大多數重構場景。

JetBrains：標準、專業、支撐強大

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

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

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

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

通過 JetBrains 可以很清楚的看到將被重構或重命名的變量的的全部調用以及上下文情況圖

JetBrains 生態 IDE 提供的閱讀幫助功能

能力對比

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

調    試

VS Code：幾乎可以調試一切

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

上圖顯示了一個爲了在 MacOS 上進行 C/C++ 程序調試所需要的最簡配置

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

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

JetBrains：一個調試怪物

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

上圖顯示的是運行調試且變量值變化的監控

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

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

能力對比

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

集成 Git

VS Code：內置了一個強大的源碼控制管理

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

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

在行內可以清楚的看到哪裏需要做衝突合併

合理處理衝突合併的能力，是 VS Code 的一大優勢。藉助 VS Code 自動提供的衝突解決方案，我可以通過點擊按鈕來選擇使用當前更改還是選擇使用傳入的更改。這種解決合併衝突的方式，爲我節約了很多時間。

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

在全面切換到 JetBrains 之後，我幾乎沒有碰過我的終端命令行。JetBrains 提供了包括提交、衝突解決、分支切換和分支對比等在內的源碼管理等整體功能。從我的體驗來看，JetBrains 在源代碼控制上比 VS Code 的要好得多。下面我羅列一些使用體驗的截圖：

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

內置的分支詳情展示

詳細的 git 日誌

能力對比

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

擴展性

VS Code：豐富的擴展性

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

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

JetBrains：集成生態

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

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

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

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

能力對比

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

協作能力

VS Code：基於插件實現實時共享

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

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

JetBrains：安全、分佈式

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

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

各種不同優秀的共享 IDE 的方案，在嘗試提高安全、協作能力或分佈式團隊如何協同工作上的表現是令人驚訝的。

能力對比

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

總    結

除了上面列出的 5 方面對比之外，我也知道，相對於 VS Code 的完全免費，JetBrains 對於非學生的用戶的需要收取一定的費用，這或許也是導致很多人不考慮 JetBrains 的原因之一。但是，對我而言，在使用 JetBrains 生態的幾個月的時間裏，它給我帶來了非常不錯的體驗。而且，我已經迫不及待的希望在工作中更多的去使用它們了。因此，我希望即使 JetBrains 需要花費一些費用，你也可以考慮一下它。

**原文鏈接：**https://blankly.finance/vscode-vs-jetbrains

**作者介紹：**Jeremy Liu 是一名全棧工程師，目前就職於 Blankly，擔任首席工程師。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/H7x9QHO8bLPCIY-NqE4HuQ