介绍 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 迭代中，我们发布了一个名为 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 调试。

如果您的 npm 脚本包含类似 --inspect 的调试参数，我们将自动检测到这一点并提供启动调试器的调试操作，如此处所示

NPM scripts

介绍 Logpoints

基于日志记录是一种重要调试技术的学习，我们看到了将状态检查添加到我们现有调试体验的机会。在三月份的 VS Code 迭代中，我们发布了调试功能（我们称之为 Logpoints）的第一个实现。

Logpoint 是一种断点变体，它不会“中断”到调试器中，而是向控制台记录一条消息。

Logpoints

Logpoints 的概念并不新鲜，在过去的几年里，我们已经在诸如 Visual Studio、Edge DevTools 和 GDB 等工具中看到了这个概念的不同形式，它们以 Tracepoints 和 Logpoints 等多种名称出现。

为什么以及何时使用 Logpoints？

Logpoints 的基础在于这样一个观察：在许多情况下，你并不想在应用程序的特定部分停止执行，而是想检查状态在应用程序生命周期中的变化。

Logpoints 允许你将按需的日志语句“注入”到你的应用程序逻辑中，就像你在启动应用程序之前已经添加了日志语句一样。Logpoints 在执行时注入，而不是持久化到源代码中，因此你无需提前计划，可以在需要时注入 Logpoints。另一个好处是，你不必担心在调试完成后清理源代码。

对于 JavaScript 开发人员来说，这意味着你不再需要担心留下 console.log 了 —— 直接使用 Logpoints！更棒的是，你可以将 console.log 和 Logpoints 结合使用。如果你在已经有 console.log 的代码块中插入一个 Logpoint，你将在调试控制台中看到两种类型的日志语句。

云环境中的 Logpoints

Logpoints 在云环境（或任何远程环境）中尤其有用，因为它们使你能够在远程环境中注入日志，而无需重新部署应用程序。同样重要的是，Logpoints 不会暂停脚本执行，因此与在常规断点上暂停正在运行的应用程序不同，Logpoints 不会影响你的用户。

你可以在此处了解更多关于如何在 Azure 上将 Logpoints 用于 Node.js 的信息。

支持的语言

自从 VS Code 中首次发布 Logpoints 以来，我们看到 VS Code 调试适配器的采用率不断增长，今天以下语言都支持 Logpoints：

VS Code 中的 Logpoints

如果你有兴趣在你的 VS Code 调试适配器中添加 Logpoint 支持，请查看协议中的这些更改。你也可以查看上面的调试适配器，了解每个运行时如何选择实现 Logpoints。

下一步

目前就这些，但我们还没有完成。在我们的七月迭代中，我们将改进自动附加功能，以帮助用户发现（#53640），这是基于用户反馈的。

我们希望自动附加、NPM 脚本资源管理器和 Logpoints 的引入将使使用 VS Code 进行调试更加容易。与往常一样，我们渴望听到你的反馈，因此请通过 GitHub 或 Twitter 上的 @code 联系我们。

代表 VS Code 团队：祝你编程愉快！

/Kenneth Auchenberg - Twitter 上的 @auchenberg