除錯介面卡協議的新家
2018 年 8 月 7 日 André Weinand, @weinand
七月里程碑的一個目標是將一直“隱藏”在某個不太知名的 GitHub 專案中的 Debug Adapter Protocol（除錯介面卡協議）遷移到一個更顯眼的網站（參見功能請求 #19636）。
本部落格將提供有關協議、Debug Adapter Protocol 以及此次遷移動機的一些背景資訊。
為什麼需要透過協議解耦？
來自另一篇部落格
“Visual Studio Code 是面向所有開發人員的編輯器，無論您使用何種程式語言。”
這一承諾基於（至少）兩大支柱：
- 一個可擴充套件的工具平臺和生態系統，每個人都可以輕鬆貢獻。
- 使任何程式語言都能輕鬆獲得出色工具支援的技術。
開發工具對程式語言的支援意味著：
- 基於對語言的深入理解（即“語言智慧”）的豐富編輯支援。
- 整合到編輯工具中的語言除錯支援。
後者可能會讓一些人感到驚訝，但我們始終堅信除錯是編寫原始碼的地方（即編輯器）不可或缺的一部分。除錯是開發“內迴圈”的重要組成部分。
但為新的語言向 IDE 或編輯器新增偵錯程式是一項巨大的工作，因為標準除錯功能列表並不短：
- 原始碼、函式、條件、內聯斷點和日誌點。
- 在懸停或內聯在原始碼中顯示的變數值。
- 多程序和多執行緒支援。
- 導航複雜的資料結構。
- 監視表示式。
- 帶有自動完成功能的互動式評估除錯控制檯 (REPL)。
為新語言實現這些功能不僅需要付出巨大的努力，而且令人沮喪的是，這項工作必須針對每個開發工具重複進行，因為每個工具都使用不同的 API 來實現其使用者介面。
這導致了大量的重複功能（和實現），如下圖中的藍色框所示：
當我們開始開發 Visual Studio Code 時，我們始終設想盡可能地將“前端”UI 與特定語言的“後端”實現解耦。我們希望對語言智慧和除錯支援都這樣做。
今天，我們相信我們已經實現了這個雄心勃勃的目標：
我們建立了兩個抽象協議，允許將“前端”中的編輯和除錯使用者介面與“後端”元件提供的特定語言智慧和除錯功能解耦。
“對語言的深入理解”由 Language Server Protocol（LSP，語言伺服器協議）體現，“除錯支援”由 Debug Adapter Protocol（DAP，除錯介面卡協議）體現。
Debug Adapter Protocol
Debug Adapter Protocol 背後的想法是標準化一個抽象協議，用於開發工具的除錯元件如何與具體的偵錯程式或執行時進行通訊。
由於假定現有的偵錯程式或執行時會在短期內採用此協議是不現實的，因此我們設計了一個中間元件來承擔將現有偵錯程式或執行時 API 適配到 Debug Adapter Protocol 的角色。這個中間元件變成了 Debug Adapter（除錯介面卡），這也解釋了協議的名稱：Debug Adapter Protocol。
下面是一個開發工具如何使用 DAP 與流行“gdb”偵錯程式的 Debug Adapter 進行通訊的示例：
我們假設使用者已經開始了一個除錯會話，但目前在程式的入口點停止，並希望設定（並稍後命中）一個斷點。
- 使用者透過單擊斷點槽來在特定原始檔中設定一個或多個斷點。開發工具向 Debug Adapter 傳送一個
setBreakpoints請求，Debug Adapter 將斷點註冊到 gdb 偵錯程式。 - 然後使用者按下 Continue（繼續）按鈕以恢復執行。工具向 Debug Adapter 傳送一個
continue請求，Debug Adapter 將其轉換為相應的 gdb 命令。 - 一段時間後，斷點被命中，Debug Adapter 從 gdb 收到一些通知，並將其轉換為一個 DAP
stopped事件，該事件被髮送到開發工具。 - 為了響應此
stopped事件，開發工具更新其 UI 並顯示堆疊跟蹤檢視。這會觸發一個stacktrace請求，該請求返回為單個堆疊幀顯示的所有資訊。 - 如果使用者選擇一個堆疊幀，開發工具會使用
variables請求獲取該幀的變數。
出於歷史原因，DAP 使用基於 JSON 的有線格式，靈感來自（現已過時的）V8 Debugging Protocol。請注意，此格式與 LSP 中使用的 JSON-RPC 相似但不相容。
在簡短介紹了 DAP 通訊示例之後，讓我們回顧一下 DAP 方法的特點：
這張圖片顯示了 DAP 方法的兩個重要好處：
- Debug Adapters 可以在不同的開發工具之間共享，這有助於分攤它們的開發成本。
- Debug Adapter Protocol 不侷限於 VS Code，可以用作其他開發工具中通用偵錯程式 UI 的基礎。
這些特點類似於 2016 年釋出在自己的網站上的 Language Server Protocol 的特點。
DAP 的新家
現在我們效仿了 Debug Adapter Protocol，將 DAP 規範從其舊位置遷移到了一個新網站 https://microsoft.github.io/debug-adapter-protocol 以及相應的儲存庫 https://github.com/microsoft/debug-adapter-protocol。
這次遷移應該強調 Debug Adapter Protocol 並非特定於 Visual Studio Code。例如，Visual Studio 現在也支援此協議。
在新位置，我們提供：
- 協議的概述和介紹。
- 作為機器可處理的 JSON-schema 的協議規範。
- 從協議規範自動生成的詳細文件。
- 實現該協議的Debug Adapters。
- 託管該協議的開發工具。
- 支援該協議的SDKs。
- 錯誤、功能請求和拉取請求可以在新儲存庫的Issues（問題）部分建立。
舊位置將繼續託管用於 DAP 的三個 npm 模組的原始碼：
下一步是什麼？
由於 Debug Adapter Protocol 已經面世相當長一段時間了，所以遷移到新網站並不是真正的開端，而只是搬到了一個新家...
我們想邀請所有 DAP 的現有和未來使用者訪問我們的新家，並在那裡繼續協作。例如，您可以透過向 GitHub 提交針對這些 Markdown 檔案的拉取請求來幫助保持支援工具和實現列表的最新狀態：Debug Adapters、Tools 和 SDKs。
代表 VS Code 團隊：祝您編碼愉快！
André Weinand - Twitter 上的 @weinand