引入日志点和自动附加

2018 年 7 月 12 日 Kenneth Auchenberg, @auchenberg

在过去的几个月里，我们一直致力于改进 Visual Studio Code 中的调试体验，在这篇文章中，我将讨论我们如何看待调试，介绍我们从用户那里听到的反馈，并解释我们为使 VS Code 中的调试更容易、更简单而采取的步骤。

从 VS Code 诞生以来，我们一直提供集成的调试体验，因为我们相信调试应该成为你编写和编辑源代码的地方——你的编辑器——不可或缺的一部分。

VS Code 调试体验由通用的调试器 UI 提供支持，该 UI 通过调试适配器协议 (DAP) 与我们称之为调试适配器 (DA) 的特定类型的 VS Code 扩展进行通信。DA 与真正的调试器对话，并在 DAP 与调试器的运行时特定调试协议或 API 之间进行转换。

这意味着 VS Code 的核心与特定调试器完全解耦，这种架构允许 VS Code 调试任何内容，只要有可用的调试适配器，如下图所示

观察和痛点

如今，有大量满意的开发人员定期使用 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 进程。

你可以通过从命令面板运行调试: 切换自动附加命令来启用自动附加，激活后你也可以从状态栏切换自动附加。

此功能完全消除了任何调试配置，因为我们将任何使用 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 脚本，我们将自动检测到这一点并提供一个启动调试器的调试操作，如下图所示

引入日志点

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

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

日志点的概念并不新鲜，在过去几年中，我们已经在诸如 Visual Studio、Edge DevTools 和 GDB 等工具中看到了这一概念的不同变体，名称包括跟踪点 (Tracepoints) 和 日志点 (Logpoints)。

何时以及为何使用日志点？

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

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

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

云环境中的日志点

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

你可以在此处阅读更多关于如何在 Azure 上为 Node.js 使用日志点的信息。

支持的语言

自 VS Code 中日志点首次发布以来，我们看到 VS Code 调试适配器的采用率不断增长，如今以下语言均支持日志点：

• Node.js 调试器
• Chrome 调试器
• Firefox 调试器
• Microsoft Edge 调试器
• React Native 调试器
• Python 调试器
• Dart 调试器
• Lua 调试器
• Java 调试器
• 大型机调试器

VS Code 中的日志点

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

后续步骤

目前就这些，但我们尚未完成。在七月迭代中，我们将根据用户反馈改进自动附加，以提高其可发现性（#53640）。

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

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

/Kenneth Auchenberg - Twitter 上的 @auchenberg