使用开发者工具是开发人员的日常,但多数人往往只使用其中的一小部分,很多功能其实都无人问津。在微软 Edge 项目部担任开发者工具首席产品经理的 Christian Heilmann 认为,开发者工具正变得越来越复杂和强势,要解决这个问题则需要意识到,开发者工具不该指望用户成为专家,而是要随时间推移引导他们变成专家。
以下内容节选自他近日发表的博文,源自他自己在使用工具、记录体验并查阅用户反馈时的真实经历,不仅罗列了一些开发者工具使用技巧,也提出了优化思路。
需要注意的是,本文中提及的“Chromium 浏览器”是指一切使用 Chromium 内核、并提供全部开发者工具的浏览器,其中包括 Chrome、Microsoft Edge 以及 Brave 等等。
顺带一提,Microsoft Edge 虽然是 Windows 10/11 的内置浏览器,但是基于 Chromium 内核开发,所以从平台类型的角度看类似于 Chrome。只是各款浏览器在用户体验与具体服务选项上有所区别。Edge Developer Tools 也与谷歌密切合作,产品内的不少工作成果也会被反哺到 Chromium 内核当中。最后,以下提到的部分实验只在 Microsoft Edge 当中成立,感兴趣的人可以选择相应的 Edge Windows、Mac 及 Linux 版本进行验证。好了,话不多说,马上进入正题:
- Console 不只是 “log()”
(一切附带开发工具的浏览器均遵循此标准。)
毫无疑问,除了 Elements 工具之外,Console 可说是浏览器开发者工具中使用频率最高的组成部分。人们习惯于在代码中添加“console.log()”进行调试,了解到底发生了什么。当然,实际还有更好的方法来调试脚本;但考虑到这种习惯已经相当普遍,所以我们就聊聊如何改善这种体验。
第一个问题是,如果产品上线时日志消息没有被删除,那么 Console 会发生堵塞。为了避免由此带来的信息查找障碍,最好能充分使用 Console 提供的控制台消息筛选选项。正确使用这些选项既能保证良好的跟踪能力,也可以屏蔽掉大量噪声。
微软产品经理:你不能不知道的 6 个 Web 开发者工具
我们在记录什么?
可能很多朋友在使用“console.log()”时,都仅仅忙于记录下具体值、却忘记为其添加来源。例如,在使用以下代码时,我们会得到一份数字清单,但却并不清楚这份清单的含义。
console.log(width)
console.log(height)
复制代码
解决这个问题的简单方法,就是把要记录的内容用大括号括起来。这样 Console 就会同时记录下值与名称。
console.log({width})
console.log({height})
复制代码
微软产品经理:你不能不知道的 6 个 Web 开发者工具
丰富你的 Console 词汇表
微软产品经理:你不能不知道的 6 个 Web 开发者工具
除了“console.log()”以外,大家还可以使用其他多种方法。例如用“console.warn()”记录警告消息,使用“console.info()”记录信息内容、使用“console.error()”记录错误消息。这不仅能改变 console 当中的显示内容,还能为消息建立起一种差异化记录层级,大大降低记录内容的过滤难度。
Console 中的错误与断言
微软产品经理:你不能不知道的 6 个 Web 开发者工具
在 Console 中显示错误确实要比直接弹出错误缓和得多,但我们最好能同时为产品维护或调试人员提供问题的严重性提示。这里介绍的有趣方法就是“console.assert()”,它只会在满足特定条件时记录一条消息。对于这类需求,以往大家可能更习惯于编写包含“console.log()”的“if”语句;但这里推荐大家直接使用“assert()”,这样更有利于后续清理调试代码。
跟踪事物来源
微软产品经理:你不能不知道的 6 个 Web 开发者工具
通常我们可能会添加“console.log(‘Called’)”或者类似的表达来测试某项功能是否被触发。在得到肯定的答案后,接下来当然是找出调用该方法的根源。这时候就该“console.trace()”大显身手了,它不仅能告诉我们哪些东西被调用过、还能告诉我们调用操作来自何处。
对 console 消息进行分组
如果大家有很多消息需要记录,不妨使用“console.group(‘name’)”与“console.groupEnd(‘name’)”将消息打包至 Console 中的可折叠与可扩展消息内,甚至可以设置默认情况下使用扩展或者是折叠分组。
微软产品经理:你不能不知道的 6 个 Web 开发者工具
将 console 中的大量信息显示并过滤为表格形式
如果把大量信息直接显示为日志,那阅读起来绝对让人血压上升。好在“console.talbe()”方法能够在 console 当中将这类数组式数据显示为表格形式,我们则提交想要查看的属性数组对显示内容进行过滤。
例如,我们可以使用“let elms = document.querySelectorAll(‘:is(h1,p,script’)”获取文档中的所有 H1、段落与脚本元素,并使用“console.table(elms)”将信息结论显示为表格。由于不同元素中包含大量属性与特性,所以生成的表格仍然非常难以阅读。这里我们可以使用“console.table(elms,[‘nodeName’, ‘innerText’, ‘offsetHeight’])”进一步开展过滤,最终获得一个只包含所需属性及其值的表格。
微软产品经理:你不能不知道的 6 个 Web 开发者工具
在复制和粘贴此信息时,表格结构将保持不变。这也让此功能成为将数据导入 Excel 或者 Word 的绝佳工具。
灵活运用:$() and ( ) C o n s o l e 当 中 提 供 多 种 易 于 使 用 的 便 捷 方 法 , 被 称 为 C o n s o l e U t i l i t i e r s 。 其 中 两 个 非 常 实 用 的 代 表 就 是 “ () Console 当中提供多种易于使用的便捷方法,被称为 Console Utilitiers。其中两个非常实用的代表就是“ ()Console当中提供多种易于使用的便捷方法,被称为ConsoleUtilitiers。其中两个非常实用的代表就是“()”与“$$()”,它们分别对应着“document.querySelector()”与“document.querySelectorAll()”。这些不仅能返回我们需要的 nodeList,还会将结果转换为数组,因此可以直接在结果上使用“map()”与“filter()”。以下代码就能获取当前文档内的所有链接并返回一个数组,其中的对象仅包含各链接的“href”与“innerText”属性作为“url”及“text”属性。
$$(‘a’).map(a => {
return {url: a.href, text: a.innerText}
})
- 无需源代码即可记录——Live Expressions 与 Logpoints
(适用于 Chromium 浏览器)
“console.log()”的正确使用方式,当然是放置在代码中希望获取信息的位置。但我们也可以使用它深入了解自己无法访问或变更的代码。Live Expressions就是一种无需变更代码即可记录信息的好办法。它们能够以惊人的速度记录不断变化的值,但又不会给 Console 带来太大压力、拖慢运行速度。
Logpoints 则是一种特殊的断点。我们可以在开发者工具的 Sources tool 中右键点击 JavaScript 中的任意一行并设置 logpoint。系统会提示我们输入想要记录表达式,之后即可在该代码行运行时通过 console 获取它的值。所以从技术上讲,我们完全可以在 web 的任意位置上插入“console.log()”。
- 在浏览器外也能记录 – VS Code 调试器
(适用于 Chromium 浏览器及 VS Code)
在 Visual Studio Code 中启动调试会话时,我们可以生成一个浏览器实例,并通过开浏览器开发者工具将 Debug Console 作为 Console 使用。
微软产品经理:你不能不知道的 6 个 Web 开发者工具
4. 将代码注入至任意站点——Snippets 与 Overrides
(适用于 Chromium 浏览器)
开发者工具中的Snippets是一种针对当前网站运行脚本的方式。我们可以在这些脚本中使用Console Utilities,进而编写并存储那些需要在 Console 中执行的高复杂度 DOM 操作脚本。大家可以使用 snippets 编辑器或者命令菜单,在当前文档的窗口上下文内运行脚本。如果是使用命令菜单的情况,请注意在命令开头使用!并输入要运行的代码段名称。
Overrides的作用是为远程脚本存储一份本地副本,并在页面加载时执行覆盖。例如,如果我们的整个应用程序构建过程太过缓慢,但又希望随时尝试一点新鲜设计,那么 overrides 就能发挥作用了。另外,这款工具还能在无需浏览器扩展的前提下,替换掉第三方网站中那些烦人的脚本。
- 检查与调试工具的丰富程度远超你的想象
(适用于 Chromium 浏览器)
大家对 Chromium 开发者工具的第一印象可能来自 Google Chrome、Brave 或者 Microsoft Edge 等浏览器,但这些工具的适用环境远不止于此。一切基于 Electron 的应用程序都能启用这些工具,供我们查看引擎盖之下的代码究竟是如何构建完成的。例如,我们可以在 GitHub Desktop 以及 Visual Studio Code 中使用,甚至可以利用开发者工具调试浏览器中的开发者工具本身。
观察开发者工具,可以看到它们是用 HTML、CSS 以及 TyperScript 编写而成。这样的技术使用环境令人兴奋,因为我们能清楚地看到代码运行在怎样的渲染引擎当中——这是在 Web 端永远体会不到的快乐。
微软产品经理:你不能不知道的 6 个 Web 开发者工具
Visual Studio Code 中的 Edge 开发者工具
(适用于 Microsoft Edge 搭配 VS Code 扩展)
这些工具还具有可嵌入特性,因此能够在浏览器之外加以使用。Microsoft Edge Tools for Visual Studio Code扩展就将这些工具引入了 Visual Studio Code。如此一来,我们可以直接在代码编辑器一旁使用可视化调试工具,彻底告别二者之间反复切换的烦恼。在首次使用时,系统会提示用户安装扩展;之后每当我们调试会话并单击开发者工具图标,这些工具就会应声开启。
微软产品经理:你不能不知道的 6 个 Web 开发者工具
微软产品经理:你不能不知道的 6 个 Web 开发者工具
6. 发掘更多宝藏功能……
在亲自打理开发者工具一段时间之后,我从反馈信息中总结出了几点令人遗憾的事实。首先是,虽然我们都对开发者工具的惊人表现感到兴奋,但用户往往只使用其中的一小部分。很多东西好是好的,但却总是静静躺在演示文稿和视频教程当中沉睡,压根无人问津。刚开始我们以为是因为说明文档不够着实,于是花了大量时间更新DevTools文档,确保所有功能都拥有全面的描述与解释。但事后来看情况并非如此,多数开发者只有实在没有办法(在谷歌、Stack Overflow 乃至其他社交渠道上都找不到答案)时,才会把说明文档视为最后的救命稻草。
开发者工具越来越复杂、越来越强势——谈谈我的解决思路
(适用于 Microsoft Edge)
多年以来,持续增长下的浏览器开发者工具正变得越来越强势、令人难以接近。这样的结果令人沮丧,我觉得我们应该做得更好。所以在我看来,开发者工具应该实现这样一个目标:
开发者工具不该指望用户成为专家,而是随时间推移引导他们变成专家。
我们正在尝试一系列简化操作的想法,相应的结果很快就会在 Microsoft Edge 中得到体现。其中一项探索就是“Focus Mode”,在这里界面不再显示所有工具和选项卡,而是将工具分类至不同的用例当中,例如“Elements/CSS 调试”、“源代码/JavaScript 调试”或者“网络检查”等。其核心思路非常简单,就是隐藏掉一切可能令人困惑或妨碍效率的工具,只显示与当前工作相关的工具。
微软产品经理:你不能不知道的 6 个 Web 开发者工具
我们正在研究的另一项功能是“informational overlays”。我们打算提供一个帮助按钮,用于开启开发者工具的覆盖框,具体解释每款工具是什么、如何使用并列出说明文档链接。我们希望这一设计能够帮大家更轻松地了解各项功能。
微软产品经理:你不能不知道的 6 个 Web 开发者工具
代码编写与结果调试之间仍然相互脱节
(适用于 Microsoft Edge)
虽然如今的开发者工具已经相当完善,但创作与调试之间仍然存在一定程度的脱节。大多数情况下,我们只能编写代码、创建应用程序,之后转向浏览器查看哪些部分起不到应有的作用。接下来,用户会使用浏览器开发者工具调整并修复这些问题。但最大的麻烦这就来了:我们要怎么把由浏览器开发者工具创建的变更返回至代码?大多数情况下,答案只有一个:复制加粘贴,或者记下实际修改内容。
我们目前正在研究两种方法,希望降低整个调试与修改流程。一种就是尽量使用 Visual Studio Code 替代开发者工具中的编辑器,并在用户使用开发者工具时直接更改磁盘驱动器上的文件。另一种则是借助 VS Code 扩展来实现,允许大家在使用开发者工具时直接修改编辑器内的源代码,并在完成后明确指示是否要替换掉磁盘上的真实源文件。
最后,Christian Heilmann 呼吁开发者积极反馈意见,“我们努力在让反馈与响应变得更加便捷。例如,Visual Studio Code 扩展就提供了醒目的链接与按钮,可供随时上报问题和申请功能。”