为什么我要花 20% 的时间来修复错误？这是正常的吗？ [关闭]答案

【问题标题】：Why do I spend 20% of my time fixing bugs? Is this normal? [closed]为什么我要花 20% 的时间来修复错误？这是正常的吗？ [关闭]
【发布时间】：2010-01-17 10:28:43
【问题描述】：

我刚刚开始用 C、C++、Java、ASP.NET、C#、Objective-C、I-Phone 等编写代码。

但我不明白为什么我必须花费 20% 的时间来修复错误。

我只是按原样学习了那些编程语言。大多数程序员都面临这种类型的问题吗？

【问题讨论】：

您的意思是您自己的代码中的错误吗？当然，这是开发周期的一部分。如果您的意思是，您计划在 20% 的时间内对公司的其他代码进行定期维护，我想这并不过分，尽管我希望这会成为您接受这份工作时谈判的一部分。
哇，刚开始编程，但已经用 5 种语言在 iphone 上完成了。 20% 不足以修复所有的错误...
这怎么会“不是一个真正的问题”？就因为写得不好？我在这里很不适应，但英语可能不是他的母语！
没有20%是不正常的，是非常少的。
其实，当你在编程上变得更好时，你实际上会花更多时间去调试，因为实际的代码编写部分会更短！

标签： programming-languages project-management

【解决方案1】：

您不一定要花费 20% 的时间来修复错误，但是 - 是的 - 大多数程序员都必须面对修复错误的问题。希望您能够在错误修复上花费不到 20% 的时间，如果您不小心，它甚至可能会花费您更多的时间。

无论您是多么优秀的程序员，您都极有可能在某个时候引入一些错误。如果您对unit testing 有纪律，您可以希望尽可能避免错误。如果您想尽最大努力避免错误，我强烈建议您查看Test Driven Development (TDD)。

如果您需要入门帮助，有几个关于 StackOverflow 上的单元测试和 TDD 的问题。以下是其中一些：

【讨论】：

+1 完全同意。事实上，在我们开始单元测试和 TDD 之后，我会说我们将大约 5% 的时间花在了 bug 上。没有谎言。
非常好，但我不喜欢“大多数程序员”和“极有可能”的谈话。每个程序员都花时间修复错误。您将引入错误。
@abyx：你说得对！但如果我说每个程序员都会引入错误，我敢肯定有人会声称他们不会——即使他们确实会......
您需要迎合他们吗？这是一个安全且可证明是真实的概括，因为人们通过反复试验来学习，无论他们说什么，它只是采用与他们设想的“反复试验”不同的形式。

【解决方案2】：

不，大多数程序员的情况都差于 20%。

如果您想领先于游戏，您将开始编写测试以配合您的代码。谷歌：

先测试编程
测试驱动设计
行为驱动设计

【讨论】：

+1 但我可以建议您从最后一点中删除最初的“设计”吗？
... 并将其添加回它所属的第二行。谢谢你的收获。

【解决方案3】：

Bug 总是会出现，应该尽快解决，这样代码在您的脑海中是新鲜的。

【讨论】：

【解决方案4】：

例如你会写，但在你的帖子中有一些“错误”：逗号后没有空格，逗号前有空格，点后没有空格，“程序员”不是某人的名字，所以最好“程序员”。现在您可以用 20% 的时间来修复它们。

【讨论】：

【解决方案5】：

这是一个奇怪的问题。如果我可以冒昧地改写它...

为什么我要花这么多时间来纠正自己的错误？

把你的精力集中在一开始就不要制造它们。您可以做很多事情来尽量减少错误：

提前清楚您的方法的输入、输出和副作用是什么。
将您的问题分解为易于编写的小型函数和方法。
编写大量测试。
编写可测试的方法。
在点击编译/运行按钮之前校对代码。
请其他人校对。

随着经验的积累，您会发现容易犯的错误变得不那么频繁，而困难的错误（通常是由于糟糕的设计或库中的未知行为导致）开始占用您更多的时间。

【讨论】：

【解决方案6】：

修复错误是编程的一部分，无论你喜欢与否，它都会一直存在。

只要有编程，它就一直存在，直到我们不再编程为止。

它很常见，您可以在许多常见的编程笑话中找到它。

和韦恩一样，大多数人将超过 20% 的时间花在调试上。

就我个人而言，我认为调试让编程变得有趣，并不是因为它本身很有趣，而是因为你需要很长时间才能修复它，一旦你修复了它，你就会有一种压倒性的感觉，所以“WOOHOO！我做到了！ "

再次，我同意 Wayne 的观点，即尝试使用这些编程技术，但是，它们带走了编程的所有乐趣。

我发现调试时有用的一件事是休息一下，然后在几分钟后返回代码发现错误，最难的部分是获得停止编程和休息的意愿。

【讨论】：

@Laith，如果你所说的“有趣”是指“由于生产中出现错误而在凌晨 2 点被轮班主管叫醒”，那么是的，它消除了其中的一些（不是全部）愉快的活动。不过，仍有很多谜题需要解决。您只需在第一次编写代码时解决它们，而不是在凌晨 3 点。通常。
@Wayne：你不是凌晨 2 点开始编程吗？耻辱！ ;)
嘘。我不希望他们仅仅因为我有点闭眼就剥夺我的“程序员”头衔。
@Wayne：是的，让我们保守这个肮脏的小秘密。

【解决方案7】：

不，您不要必须花费 20% 的时间来修复自己的错误。

没有人提到 PSP/TSP，但减少错误修复时间是 PSP（个人软件流程）的全部意义所在。通常，它可以使您从一开始就将错误修复时间减少到不到 10%，方法是通过形式化您的设计文档并根据清单对其进行审查；标准化您的代码，并根据代码审查清单对其进行审查；然后继续编译和测试。

最终，您可以将错误修复时间减少到接近零，因为您可以更好地审查您的设计和代码。基本思想是修复设计文档中的错误或查看代码所需的时间要少得多；比在单元测试中查找和修复错误所花费的时间要多，比集成测试还要多。

如果您使用良好的设计审查、代码审查和单元测试，您的错误修复时间几乎每次都应该低于 10%，我平均低于 7%（根据我的统计数据）。

【讨论】：