🚀 在 VS Code 中

Logpoints 和自動附加功能簡介

2018 年 7 月 12 日 Kenneth Auchenberg,@auchenberg

在過去幾個月中,我們一直忙於改進 Visual Studio Code 中的偵錯體驗。在這篇文章中,我將談談我們如何看待偵錯、呈現我們從使用者那裡聽到的意見回饋,並說明我們為了讓 VS Code 中的偵錯更輕鬆簡單而採取的步驟。

自 VS Code 啟動以來,我們就隨附了整合式偵錯體驗,因為我們認為偵錯應該是您撰寫和編輯原始碼的核心部分——您的編輯器。

VS Code debugger

VS Code 偵錯體驗由通用的偵錯工具 UI 提供支援,該 UI 透過偵錯工具介面協定 (DAP) 與特定類型的 VS Code 擴充功能(我們稱之為偵錯工具介面卡 (DA))進行通訊。DA 與真正的偵錯工具通訊,並在 DAP 與偵錯工具的執行階段特定偵錯協定或 API 之間進行轉換。

這表示 VS Code 的核心與特定的偵錯工具完全分離,並且只要有可用的偵錯工具介面卡,這種架構就允許 VS Code 偵錯任何事物,如此處所示


VS Code debugging architecture


觀察與痛點

如今,有許多滿意的開發人員定期使用 VS Code 進行偵錯,但是,作為我們使命的一部分,我們希望讓偵錯更輕鬆,並讓更多開發人員可以使用。

為此,我們開始對話,以更好地了解 VS Code 中偵錯的痛點,並了解為何有些開發人員根本不使用我們的偵錯工具。

以下是我們的觀察

偵錯組態很難設定正確

VS Code 是一個通用的編輯器,具有通用的偵錯工具,並非專門針對特定的堆疊或執行階段。因此,我們無法提供適用於所有人的明確預設偵錯組態。

這表示 VS Code 要求您設定偵錯工具的設定,並指定您想要如何使用正確的參數等啟動執行階段。

我們意識到這可能很難設定正確,但我們認為沒有辦法完全消除每個人的偵錯組態。但是,我們確實相信可以簡化偵錯組態,並且可以根據上下文將其縮減到最低限度。

稍後我會再回到這一點。

啟動和附加組態之間的混淆

在 VS Code 中,我們有兩個用於偵錯的核心概念:啟動附加,它們處理兩種不同的工作流程和開發人員群體。根據您的工作流程,可能很難知道哪種類型的組態適合您的專案。

如果您來自瀏覽器 DevTools 背景,您不習慣「從您的工具啟動」的概念,因為您的瀏覽器執行個體已開啟。當您開啟 DevTools 時,您只是將 DevTools 附加到您開啟的瀏覽器索引標籤。另一方面,如果您來自 Java 背景,您的編輯器為您啟動 Java 程序是很正常的,並且您的編輯器會自動將其偵錯工具附加到新啟動的程序。

解釋 啟動附加 之間差異的最佳方法是將啟動組態視為在 VS Code 附加到您的應用程式之前,說明如何在偵錯模式下啟動應用程式的配方,而附加組態則說明如何將 VS Code 的偵錯工具連接到已經在執行的應用程式或程序的配方。

啟動組態的價值在於,它們為您提供了一種方法,可以透過建立可重複且可與您的專案和團隊共用的組態,來減輕使用正確偵錯參數啟動應用程式的一些認知負擔。

但是,當我們與開發人員討論他們如何啟動應用程式時,我們看到了一個模式,並做了一個重要的觀察

觀察:許多使用 VS Code 的開發人員非常喜歡整合式終端機,並且依賴命令列工具來啟動他們的應用程式。對於許多人來說,在終端機中執行命令,然後從編輯器附加偵錯工具是一種更自然的工作流程。這類似於在瀏覽器啟動後開啟 DevTools。

這個觀察是關鍵,我們意識到許多使用者不想要編輯器中完整的「神奇」啟動體驗。他們希望將編輯器保留為編輯和偵錯原始碼的地方,並使用終端機來啟動應用程式、執行建置指令碼等。這是我們在 VS Code 內部提供整合式終端機體驗的原因之一,因為我們相信良好的功能性 UI 應該與終端機共存並良好整合。

許多開發人員不使用中斷點,因為他們正在檢查狀態變更

在查看開發人員如何偵錯他們的應用程式時,我們還看到了另一個有趣的模式:使用記錄而不是中斷點。

用於偵錯的記錄並不是一個新概念,但這個觀察很重要

觀察:傳統的偵錯工作流程最關注減慢執行速度以檢查程式邏輯,而記錄工作流程通常涉及檢查程式狀態及其在應用程式正常執行期間如何變更。這裡的基本觀察是,這兩種技術用於不同的偵錯目的。

這種觀察對於 JavaScript 開發人員尤其相關,他們主要處理管理狀態的複雜性,這可能解釋了為何大多數 JavaScript 開發人員仍然更喜歡在他們的原始碼中新增 console.log,而不是使用指令碼偵錯工具。

自動附加至 Node 程序

當反思一些開發人員如何使用整合式終端機啟動他們的偵錯工作階段時,我們看到了一個獨特的機會出現。透過利用我們在 VS Code 內部從您的編輯器和整合式終端機取得的上下文資訊,我們可以偵測您的上下文並推斷您想要偵錯的意圖,這可以為 Node.js 開發人員提供更簡單的偵錯體驗。

因此,在 VS Code 的 3 月迭代中,我們發布了一項稱為 Node 自動附加的新功能,該功能使 Node 偵錯工具能夠自動附加到從 VS Code 整合式終端機以偵錯模式啟動的 Node.js 程序。

您可以透過從命令面板執行 偵錯:切換自動附加 命令來啟用自動附加,並且一旦啟用,您也可以從狀態列切換自動附加。


Auto attach


此功能完全消除了任何偵錯組態,因為我們將任何以 node --inspect 啟動的 Node.js 程序解釋為偵錯意圖。當與整合式終端機結合使用時,這是一種更簡單的偵錯體驗,允許開發人員以他們自己的方式啟動他們的應用程式,同時消除偵錯組態!🎉

NPM 指令碼與偵錯

許多 Node.js 開發人員依賴 npm 指令碼來啟動應用程式或啟動偵錯工作階段,我們也有一些關於這方面的好消息:自動附加也適用於 npm 指令碼。如果您執行 npm run debug,並且 "debug" 指令碼是 "node --inspect" 或任何其他包含 --inspect 的命令,則自動附加將偵測到這一點並附加偵錯工具 🎉

我們也意識到,有些開發人員想要更視覺化的方式來尋找和執行他們的 npm 指令碼,因此在 我們的 2018 年 4 月迭代中,我們新增了一個新的 NPM 指令碼瀏覽器,讓您可以直接從 UI 瀏覽和執行您的 NPM 指令碼。作為我們簡化偵錯組態工作的一部分,我們也讓您可以直接從瀏覽器啟動 Node.js 偵錯,而無需建立偵錯組態。

如果您有一個包含偵錯引數(例如 --inspect)的 npm 指令碼,我們將自動偵測到這一點,並提供一個啟動偵錯工具的偵錯動作,如此處所示

NPM scripts

Logpoints 簡介

基於記錄是重要的偵錯技術的認知,我們看到了一個機會,可以將狀態檢查新增到我們現有的偵錯體驗中。在 VS Code 的3 月迭代中,我們發布了我們稱之為 Logpoints 的偵錯功能的第一個實作。

Logpoint 是一種中斷點變體,它不會「中斷」到偵錯工具中,而是將訊息記錄到主控台。

Logpoints

Logpoints 的概念並不新穎,在過去幾年中,我們在 Visual StudioEdge DevToolsGDB 等工具中看到了這個概念的不同形式,名稱包括 Tracepoints 和 Logpoints

為何以及何時使用 Logpoints?

Logpoints 基於以下觀察:在許多情況下,您不想要停止應用程式特定部分的執行,而是想要檢查狀態如何在應用程式的生命週期中發生變化。

Logpoints 允許您將隨需記錄陳述式「注入」到您的應用程式邏輯中,就像您在啟動應用程式之前已將記錄陳述式新增到您的應用程式中一樣。Logpoints 在執行階段注入,而不是持久儲存在原始碼中,因此您不必提前計畫,而是可以在需要時注入 Logpoints。另一個好處是,您不必擔心在完成偵錯後清理您的原始碼。

對於 JavaScript 開發人員來說,這表示您不必再擔心留下 console.log 了——只需使用 Logpoints!更好的是,您可以結合使用 console.log 和 Logpoints。如果您將 Logpoint 插入到已經有 console.log 的原始碼區塊中,您將在偵錯主控台中看到兩種型別的記錄陳述式。

雲端環境中的 Logpoints

Logpoints 在雲端環境(或任何遠端環境)中尤其有用,因為它們使您能夠將記錄注入到遠端環境中,而無需重新部署您的應用程式。同樣重要的是,您不會使用 Logpoints 停止指令碼執行,因此您的使用者不會受到影響,這與在常規中斷點上停止執行中的應用程式不同。

您可以閱讀更多關於如何在 Azure 上使用 Node.js 的 Logpoints 的資訊。

支援的語言

自 VS Code 中首次發布 Logpoints 以來,我們看到 VS Code 偵錯工具介面卡越來越多地採用它,如今,以下語言支援 Logpoints

VS Code 中的 Logpoints

如果您有興趣在您的 VS Code 偵錯工具介面卡中新增 Logpoint 支援,請查看協定中的這些變更。您也可以查看上面的偵錯工具介面卡,以了解每個執行階段如何選擇實作 Logpoints。

後續步驟

目前就這樣,但我們還沒完成。在我們的7 月迭代中,我們正在改進自動附加功能,以幫助探索性 (#53640),這基於使用者意見回饋。

我們希望 Logpoints、自動附加和 NPM 指令碼瀏覽器的推出將使 VS Code 的偵錯更容易。與往常一樣,我們渴望聽到您的意見回饋,因此請透過 GitHubTwitter 上的 @code 與我們聯繫。

謹代表 VS Code 團隊:祝您編碼愉快!

/Kenneth Auchenberg - Twitter 上的 @auchenberg