调试：了解有关某些修复程序为何起作用的详细信息？[关闭]

调试时，有时会发现我做了一些更改，但我不是100％知道为什么这些更改可以纠正程序中的某些错误。是否必须了解有关为什么会出现某些错误以及为什么某些更改会消除这些错误的每个细节？还是在开发人员中有时不真正知道有关修复程序为何起作用的细节而使程序正常工作，这是常见的吗？

我要说的是，必须了解有关为什么会出现某些错误以及为什么某些更改会消除这些错误的每一个细节，而且对于开发人员来说，有时有时是在不真正了解该修复程序为何起作用的情况下使程序正常工作的，这也是很常见的！

在不了解导致错误或更改的原因的情况下更改事物直至错误消失的技巧通常被称为“伏都教编程”，这并不是一种夸奖。如果您不了解是什么原因导致的，那么您根本无法确信自己已真正修复了错误，而不是针对正在调查的特定情况部分修复了该错误。

在最坏的情况下，除了移动bug之外，您什么也没有做：我记得从uni的第一年计算开始，当许多学生第一次学习C和指针时，指针bug经常在改变事物时停止出现。因为更改会重新排列内存中的数据结构，足以使指针错误在内存的另一位上mp脚，所以它们是随机的。显然，这并没有帮助在所有。

但是，话虽如此，编程的商业现实常常是，使客户满意而已修复错误比满足自己更重要。如果您不知道是什么原因引起的，我绝不建议您声明已修复的问题，但是，即使您“不确定100％地” 知道是什么原因造成的，您仍然可以看到某些代码有问题并进行了重新设计要显示的错误，有时您只需要继续处理下一个错误，然后客户端就您的缓慢进度大声尖叫。

如果您认为客户对花费很长时间来解决错误感到不满，请想象他们会对您声称已修复的重复出现的错误或对某件事的修复使其他情况变得更糟而感到生气。如果您的修复仅是一种解决方法或缓解措施，则客户通常仍然会欢迎它，但是您必须诚实地知道它是什么，并且为了真正修复它，您需要放置尽可能多的日志。

如果您确定已解决问题，但不知道为什么会解决问题，请询问某人。我认识的大多数工程师都喜欢这样的问题，因为它背后的奥秘。

通常，在错误不再存在之前进行更改通常是一种不好的做法，但是对于某些人来说，这是一个现实。

我坚决认为，您永远不要编写不了解其作用或原因的代码。即使已解决了要修复的错误，您怎么能确定—没有破坏其他任何东西？

通常，在解决问题/错误之前-您应该进行潜在原因评估/分析，以确定问题发生的原因以及是否可以复制。然后，您应该阅读代码并理解为什么代码导致错误发生。有了了解之后，您就可以开始研究如何解决问题并确定更改将影响的其他领域。单元测试确实可以在这里提供帮助！

我已经看到人们为解决问题而进行了许多代码更改（这很棒），但是不幸的是，它引入了其他问题，因为开发人员没有意识到他们所做更改的全部影响。这些“修补程序”中的许多只是掩盖了原始问题的根本原因，并且引入了复杂性和更多错误。

话虽如此，我已经完全通过关联解决了代码中的许多问题。我在其中进行了更改/重做/重构的地方，并修复了其他突出的错误。因此，尽管我不知道最初是什么原因造成的，但我发现了不可靠的代码并“修复”了它-碰巧也修复了这些错误。我将通过单元测试和集成测试来涵盖此类更改，以确保功能的业务和技术要求的完整性。

还是在开发人员中有时不真正知道有关修复程序为何起作用的细节而使程序正常工作，这是常见的吗？

至少有三个大问题：

1. 它导致了一种黑魔法思维定式，您放弃了可以理解代码的想法，而只是开始四处移动，希望问题会消失。这在编程上等同于将食物推到盘子上，希望使您的晚餐看起来足够吃，以至于父母不会让您多吃蔬菜。

2. 除非您了解a）问题所在，以及b）更改如何解决问题，否则您就无法知道该错误实际上是已修复或仅被更改掩盖了。

3. 该错误可能尚未修复，并且在不久的将来会再次叮咬您。

我看到两种情况：您正在做其他事情，并且错误停止发生，只要其他事情没有破坏其他事情，您几乎就必须放进去–您做了需要/想要的事情，并且不可预见且莫名其妙的积极副作用。

另一个是您正在处理此错误，并且通过随机更改使一切正常，这是不可接受的。如果您不知道旧代码在做什么错，那么您可能不知道新代码在做什么错。

我真的没有想到要检查第二种情况的充分理由-如果这是一个严重的错误，那么正确解决这个问题至关重要。如果这是一个非关键错误，至少您可以确保没有在“修复”中引入一个关键错误。

还是在开发人员中有时不真正知道有关修复程序为何起作用的细节而使程序正常工作，这是常见的吗？

我曾经认为这几天很普遍。那是因为Google和Stackoverflow。您的代码有问题，只需将其谷歌搜索，找到解决方案，解决问题，然后继续下一个问题。