ACM通信
Kode恶性
分而治之
信贷:ITNEXT
亲爱的KV,
我们的许多新开发人员——那些只使用过git的人——似乎只有通过使用git的bisect命令才能在代码中找到bug。这有几个令人不安的原因。首先，一旦他们发现了导致问题的更改发生在哪里，他们往往不了解原因，只知道它发生在版本X和版本y之间。第二，他们似乎不了解以这种方式调试的限制，这可能是一个更适合您而不是我向您描述的话题。您是否发现这种做法变得越来越普遍，可能会削弱良好的调试?
它们由二分
亲爱的它们,
几乎所有的新工具都是福也是祸，KV的忠实读者现在应该知道了，能够快速地平分一组更改也没有什么不同。让自动化接管检查更改、构建系统、运行测试、查看测试是否失败的繁琐工作绝对是一件好事，然后如果测试没有以正确的方式失败，就重新进行这些工作，直到发现引入bug的更改。这种工作是你希望自动化的，因此，在这种情况下，它是一种祝福——一种有限的祝福，但仍然是一种祝福。我是说，这不是天上掉下来的甘露吧?
你要我抱怨的(你是要我抱怨，对吧?)是这样一个工具如何造就懒惰的思考者，进而造就懒惰的工程师。在我们讨论这种自动化是否会导致懒惰之前，还有一些问题需要讨论。
当且仅当你有一个完全理解的bug，并且100%的一致性出现，这样二分法就可以工作，像二分法这样的工具是很好的。如果你有一个海森堡，或类似的微妙的东西，只会偶尔失败，平分是没有用的;虽然我们不希望我们的系统中出现任何bug，但我们知道这些微妙的bug是最难修复的，它们会让我们——嗯，我们中的一些人——真正地批判性地思考我们正在做的事情。
时间错误、分布式系统中的错误，以及我们在构建日益复杂的软件系统时所面临的所有困难问题，还不能通过简单的二分法来解决。通常情况下，对于一个复杂的问题，编写一个可用的平分测试(你必须编写一个该死的东西来让平分告诉你错误的更改在哪里)要比在树的顶端分析问题要花更长的时间。
开发人员经常无法理解的另一件事是，bug可能与之前的任何更改都无关;它可能就在他们面前，盯着他们，橙色和黑色。我见过几个开发人员，他们完全相信错误是“别人的问题”，反复运行平分，最后才意识到真正的问题在他们最新的、未提交的更改中。在调试过程中嘲笑别人是不公平的，而且，对于KV来说，这是一种生命和肢体的风险，但是是还该死的诱人。
bisection为所有开发人员提供的只是另一个查找代码中的bug的工具。当然，bug必须易于测试，很可能在分布式系统中不存在，也不可能是定时或heisenbug，但这仍然比手工查找这些更简单的bug或编写自己的脚本来完成bisect要做的事情要好。
这个工具会让我们变笨吗?可能不会。它所做的可能是帮助缺乏经验的开发人员发现bug;然而，如果开发人员希望学习，该工具不会阻止他们学习，这就是为什么这样的工具对一些人来说是福音，对另一些人来说是缓冲。
KV
相关文章
在queue.acm.org
Kode恶性
在活动系统上调试
https://queue.acm.org/detail.cfm?id=2031677
MongoDB的JavaScript Fuzzer
罗伯特郭
https://queue.acm.org/detail.cfm?id=3059007
调试分布式系统
伊万·贝什斯特尼克，帕蒂·王，尤里·布伦，迈克尔·d·恩斯特
https://queue.acm.org/detail.cfm?id=2940294
数字图书馆是由计算机协会出版的。版权所有©2021 ACM, Inc.
没有发现记录