这有什么寓意？ [关闭]

Question

关闭。 这个问题是基于意见的。 它目前不接受答案。

---

想改进这个问题？ 更新问题，以便可以通过编辑这篇文章用事实和引文来回答。

3 年前关闭。

改进这个问题

一位伟大的人物曾经说过：

“调试的难度是编写代码的两倍。因此，如果你尽可能巧妙地编写代码，那么根据定义，你还不够聪明，无法调试它。”

是真的吗？ 你认为这有什么寓意？

Answer 1

好吧，不确定我完全同意这一点。 就我而言，它并不总是正确的。 的确，有时调试非常困难，因为所有抛出的异常，您可能会遇到多个错误。 的确，在某些情况下，与编写代码相比，您需要做更多的研究来解决调试时的错误。

此外，我总是建议任何人仔细编写代码，多次阅读以确保您没有犯任何明显的错误，然后进行调试。 如果你这样做，你很难调试代码的可能性肯定会降低！

Answer 2

感觉像是一种寓言。 寓言通常从一个特定的角度展示世界，并不一定反映真相（无论如何这是一个相对的概念：）。 但是比喻确实会让你好奇——这就是它们的作用所在。

本案也不例外。 调试并不总是困难的。 但是调试是一种非常没有效率的花费工作时间的方式。 这是查找错误的最慢、最复杂和最昂贵的方法之一。 更好的方法是预防错误而不是对抗错误。 调试应该被视为最后的手段，当一个错误仍然以某种方式进入你的代码时，尽管你建立了所有的防线。 如果您确实求助于调试，请确保您专注于应用有助于在最早阶段检测错误的实践，而不是磨练您使用调试器的技能（尽管它也可能有用）。

这种错误预防或早期检测的做法包括以下内容：

• 保持编码风格。 公司通常有编码标准——这些标准应该保持最新并允许包含新的实践。 当您使用的语言正在快速发展时，这一点尤为重要。 Google C++ Style Guide是一个好的编码标准应该是什么样子的例子。

• 结对编程。 如果有两个人处理代码，则更容易、更快地发现错误。 这种方法确实有效，但首先它很昂贵，其次并不是每个人都觉得舒服。 所以我不会推荐它作为一种普遍的做法。 但它确实有助于在编写新代码时避免大多数错误。

• 代码审查。 除了错误修复之外，代码审查还允许开发人员彼此共享知识并讨论高级问题。 这是一项重要且必要的实践。 您只需要弄清楚您的团队可以在代码审查上高效地花费多少时间，以保持质量和时间消耗之间的平衡。 代码审查在 Steve McConnell 的“Code Complete”中有详尽的解释。

• 使用单元测试测试新编写的代码。 这种实践的更高级版本称为测试驱动开发(TDD)。 与要测试的代码一起编写的测试几乎可以帮助您立即找到并修复大量错误。 编写单元测试的做法有一个有趣的副作用：由于必须测试您的类和函数，它们往往会变得更简单且耦合度更低，这会提高代码的整体质量和可读性。

• 静态代码分析。 它是自动代码审查，可以这么说，审查是由软件工具而不是人类程序员完成的。 一方面，软件工具不擅长检测算法中的高级错误； 另一方面，它们非常擅长检测人眼不易察觉的拼写错误（例如：1、2、3 ） 。

• 还应使用动态代码分析、回归测试等方法。 但是这些，与之前的做法不同，我考虑的是第二道防线。

那么，“这有什么寓意？”

我认为寓意是，如果您必须经常使用调试器来查找错误，那将是一个非常糟糕的迹象。 这意味着您的整个开发过程从一开始就没有正确组织。 它可以通过采用上面讨论的早期错误检测实践来改进。