Debugging 调试：高级与低级错误

您通常花在调试高级错误和低级错误上的时间的大致比例是多少

在本次讨论中，高级错误是指不正确的算法、对输入数据和/或操作环境的错误假设、在初始实施过程中被忽略的情况、忘记处理边界条件/边缘情况等，它们还可能包括糟糕的设计决策，这些决策会在代码中引入限制，并且不容易更改，即使这会扩展bug的定义。换句话说，高级bug是由于没有表达您应该表达的意思而导致的bug

低级错误是指诸如内存管理和损坏问题、非高级错误导致的空指针取消引用、通过编译器的细微语法错误、处理数组时出现的一个错误等等。换句话说，它们是由于没有按照您的意思编码而导致的错误

---

另外，为了便于比较，您主要使用哪种语言？您主要从事哪种类型的编程？

根据您的定义，我看到的几乎所有bug都是“高级”bug

---

我使用.net框架在C#中工作。框架会处理几乎所有您定义为低级错误的东西。

低级错误通常只由编译器修复。因此，首先看高级错误，然后看低级错误（如果需要的话）。因为试图建造一座建筑物，并想在构造薄弱的基础上建造坚固的墙是完全没有用的

---

这很有趣，但却是真的。想想看。

如果我正确理解了你的问题，你可以将错误分为两类——一类是由糟糕的编程实践引起的，另一类是由设计和规范中的问题引起的。假设我的理解确实正确，我想说的是，作为一名开发人员，我花了更多的时间跟踪低级错误，特别是当它们很难复制时（是的，该死的多线程错误，我在跟你说话，它只发生在生产中！）。另一方面，设计级和规范级错误通常会导致项目严重延迟，但更容易复制和在代码中定位。

我很抱歉。但这可能很快在“主观和争论性”下@Ravi-Nah关闭。不爱争论。你关于低级和高级bug的例子对我来说似乎是矛盾的。例如，您提到一个未处理的边缘案例是一个高级bug，但在循环中，null指针异常和off by one错误都是低级bug。我认为这三个都是算法中的边缘情况，在规范中没有特别提到，或者您将称为高级错误。所有这些通常都是由于开发人员未能正确测试而导致的。如果您想减少调试时间，请研究测试驱动开发（或至少是单元测试）。这正是我要说的。如果您将超过2%的调试时间花在这里被归类为“低级”错误上，那么也许是时候升级您的工具链了！：）但是，如果你在设计本身时出错了，或者你认为是一个错误的算法，那又有什么用呢？在我这些天工作的商业软件中，有相当多的商业逻辑是毫无意义的。有时，当我试图推断边缘情况下的行为时，我弄错了——也就是说，不是人们想要的产品。这就是我的意思，不是一个完全错误的设计。调试…哦，我记得我的问题。。