肆意妄为的调试行为
保持您的调试消息清晰、有用且不烦人。
亲爱的 KV，为什么在程序中添加日志的人缺乏区分日志消息的创造力？如果它们都说同样的事情——例如，DEBUG——就很难分辨发生了什么，甚至不明白之前的程序员最初为什么要添加这些语句。
捕捉故障：调试的记录和重放方法
与 Robert O’Callahan、Kyle Huey、Devon O’Dell 和 Terry Coatta 的讨论
当 Mozilla 开始开发名为 rr 的记录和重放调试工具时，目标是为捕获 Firefox 浏览器中低频非确定性测试失败提供一种实用、经济高效、资源高效的方法。随后的许多工程努力都投入到确保该工具能够以最小的开销兑现这一承诺。然而，出乎意料的是，rr 将在 Mozilla 之外得到广泛使用——不仅用于查找难以捉摸的故障，还用于常规调试。
调试心态
理解学习策略的心理学有助于培养有效的解决问题能力。
软件开发人员花费 35-50% 的时间来验证和调试软件。调试、测试和验证的成本估计占软件开发项目总预算的 50-75%，每年超过 1000 亿美元。虽然工具、语言和环境减少了花在单个调试任务上的时间，但它们并没有显着减少调试的总时间，也没有减少调试的成本。因此，在开发过程中过度关注消除错误会适得其反；程序员应该将调试视为一种解决问题的练习。
石刀和熊皮
如果您看一下软件工具领域，您会发现大多数开发人员使用开源工具；或者来自最近改革的专有软件之家 Microsoft 的工具，该公司已经意识到其 Visual Studio Code 系统是将人们诱入其平台的好方法；或者最终是 Apple，其工具仅用于其平台。在专业市场中，例如深度嵌入式、军事和航空航天，存在专有工具，这些工具通常比开源同类工具差得多，因为此类工具的市场很小但利润丰厚。
实践研究：分布式系统跟踪和调试；示例编程
专家策划的 CS 研究最佳指南
本期“实践研究”涵盖了分布式系统和编程方法论中两个令人兴奋的主题。首先，Peter Alvaro 将带我们了解最近用于调试世界上一些最大和最复杂系统的技术：现代分布式系统和面向服务的架构。Peter 调查的技术可以揭示分布式调用图混乱中的秩序。其次，Sumit Gulwani 说明了如何在不显式编写程序的情况下进行编程，而是从示例中合成程序！Sumit 介绍的技术允许系统从说明性示例中“学习”程序表示，从而允许非程序员用户创建越来越重要的函数，例如电子表格宏。
外包责任
当调试器让您失望时，您会怎么做？
亲爱的 KV，我被分配协助一个新项目，并且一直在查看团队放在内部 wiki 上的公认简陋的文档。我花了一天左右的时间盯着似乎是他们打算集成到他们一直在构建的系统中的开源项目长列表，但我找不到在哪里描述了他们的原创作品。
摆脱疯狂的道路
调试器和断言
KV 继续咬牙切齿，因为他看到代码中加载了调试语句，如果编写代码的程序员能够自信且熟练地使用调试器，这些语句将完全没有必要。如果有人足够幸运能够访问到一个好的调试器，那么应该向他们通常感谢的任何对象表示极大的感谢，并使用该死的东西！
使用跟踪增强调试
模拟器开发中使用的一项基本技术是任何程序员工具箱的有用补充。
创建模拟器来运行旧程序是一项艰巨的任务。您需要彻底了解目标硬件以及模拟器要执行的原始程序的正确运行。除了功能正确之外，模拟器还必须达到以原始实时速度运行程序的目标性能。实现这些目标不可避免地需要大量的调试。错误通常是模拟器本身中的细微错误，但也可能是对目标硬件的误解或原始程序中实际已知的错误。（原始程序的二进制数据也可能已被微妙地损坏或不是预期的版本。）
分而治之
二分法的使用和限制
如果您遇到偶尔才会失败的海森堡 bug，二分法就毫无用处。这些细微的错误是最难修复的，也是让我们批判性地思考我们正在做的事情的错误。定时错误、分布式系统中的错误以及我们在构建日益复杂的软件系统时面临的所有难题，目前还无法通过简单的二分法来解决。通常情况下，为一个复杂问题编写一个可用的二分法测试比在树梢分析问题花费的时间更长。
确定性记录和重放
仅关注进程的非确定性操作
本专栏介绍了与确定性记录和重放相关的三项最新研究进展，旨在展示经典用例和新兴用例。越来越多的系统使用较弱形式的确定性记录和重放。本质上，这些系统利用许多程序执行中存在的确定性，但出于性能原因有意允许一些非确定性。GPUReplay 特别体现了这种趋势，ShortCut 和 Dora 等系统也体现了这种趋势。
在实时系统上调试
这更多的是一个社会问题，而不是技术问题。
我一直在尝试调试工作中系统上的一个问题，但是运行我们生产系统的控制狂们不愿意让我访问总是发生 bug 的系统。我无法在桌面上的测试环境中重现该问题，但是每天 bug 都会在多个生产系统上发生。
调试 Google 分布式系统中的事件
专家如何在复杂的分布式系统中调试生产问题
本文介绍了 2019 年对 Google 工程师如何调试生产问题进行的研究结果，包括工程师有效调试所使用的工具类型、高级策略和低级任务的各种组合。它检查了用于捕获数据的研究方法，总结了生产调查的常见工程流程，并分享了专家如何调试复杂分布式系统的示例。最后，本文扩展了这项研究的 Google 具体细节，以提供您可以在组织中应用的一些实用策略。
调试设备
调试故障硬件的正确方法是什么？
我建议拿一把非常锋利的刀，随机切割电路板走线，直到东西要么能用，要么闻起来很奇怪！我想您不是在问导致我在另一专栏中使用“changeineer”这个词的同一个问题。我认为您有一个实际发生故障的硬件，并且您已经将之前的三个版本连同措辞严厉的信件一起寄回给了制造商，信中隐晦地提到了如果他们继续向您发送损坏的产品，将采取法律行动。
又一天，又一个 Bug
我们询问读者他们使用哪些工具来消除 bug。以下是他们的说法。
作为本期关于程序员工具专题的一部分，我们在 Queue 决定就调试主题进行一项非正式的网络调查。我们请您告诉我们您使用的工具以及您如何使用它们。我们还收集了关于那些难以追踪的 bug 的故事，这些 bug 有时会让我们想到从事其他职业。
端口不足
调试一个短暂的问题
我一直在调试一个网络问题，这个问题应该是一个简单的网络代码片段。我们有一个小型服务器进程，它监听来自我们数据中心中所有其他系统的命令，然后将命令分发到其他服务器运行。对于发出的每个命令，客户端都会建立一个新的 TCP 连接，发送命令，然后在我们的服务器确认命令后关闭连接。