You don't necessarily have to spend 20% of your time fixing bugs litteraly, but - yes - most programmers have to face the problem of bug fixing. Hopefully you'll be able to spend less than 20% on your time bug fixing, if you're not careful it might even take more of your time.
No matter how good a programmer you are it is highly likely that you'll introduce a few bugs at some time. If you're diciplined with unit testing you can hopefully avoid bugs best possible. I highly recommend you to look into Test Driven Development (TDD) if you want to do your best for avoiding bugs.
There are several questions about unit testing and TDD on StackOverflow if you need help getting started. Here are a few of them:
For example you are able to write, but in your post there are some "bugs": no space after comma, space before comma, no space after dot, "Programmers" is not a name of someone, so it's better "programmers". Now you can use 20% of your time to fix them.
It's kind of an odd question. If I may take the liberty to rephrase it...
Why am I spending so much time fixing my own mistakes?
Focus your energy on not making them in the first place. There are many things you can do to minimize mistakes:
Be clear ahead of time what the inputs, outputs, and side effects of your methods are.
Break down your problem into small, easy-to-write functions and methods.
Write lots of tests.
Write testable methods.
Proofread your code before you hit that compile/run button.
Have someone else proofread.
As you gain experience, you'll find that the easy mistakes become less frequent and the hard ones (usually resulting from poor design or unknown behaviors in libraries) start consuming more of your time.
Fixing bugs is a part of programming, whether you like it or not, it'll always be there.
It's been there for as long as programming has been around and it'll be there until we program no more.
It's so common you can find it in many of the the common programming jokes.
And like Wayne, most people spend a lot more than 20% of their time on debugging.
Personally, I think debugging is what makes programming fun, not because it's fun per se, but because it takes you so long to fix and once you've fixed it you get this overwhelming feeling so "WOOHOO! I did it!"
Again, I agree with Wayne on trying those techniques for programming, however, they take all the fun away from programming.
One thing I found useful when debugging is to take a break and then come back to your code after a few minutes, preferably after a short conversation with a friend or a phone call, you'll be amazed at how fast you can spot bugs, the hardest part is getting the will to stop programming and taking a break.
No, you DON'T have to spend 20% of your time fixing your own bugs.
Nobody mentioned anything about PSP/TSP, but reducing bug-fixing time is what PSP (Personal Software Process) is all about. Usually it enables one to reduce bug-fixing time to less than 10% right from the start, by formalizing your design documents & reviewing them according to a checklist; standardizing your code, reviewing it according to a code review checklist too; and then proceeding to compile and test.
Eventually you reduce your bug fixing time to near zero percent, as you become better at reviewing your designs and code. The basic idea is that it takes alot less time to fix a bug in the design document, or by reviewing the code; than the time it takes to find and fix a bug in unit tests, and more so than integration tests.
If you use good design reviews, code reviews and unit-testing, your bug-fixing time should be below 10% almost every time, I'm, on average, below 7% (according to my statistical data).
发布评论
评论（7）
你不一定要花 20% 的时间来随意修复 bug，但是——是的——大多数程序员都必须面对 bug 修复的问题。希望您能够花费不到 20% 的时间来修复错误，如果您不小心，甚至可能会花费更多的时间。
无论您是多么优秀的程序员，有时您很可能会引入一些错误。如果您遵守单元测试，您有望尽可能避免错误。如果您愿意，我强烈建议您研究测试驱动开发 (TDD)尽最大努力避免错误。
如果您需要入门帮助，StackOverflow 上有几个有关单元测试和 TDD 的问题。以下是其中的一些内容：
You don't necessarily have to spend 20% of your time fixing bugs litteraly, but - yes - most programmers have to face the problem of bug fixing. Hopefully you'll be able to spend less than 20% on your time bug fixing, if you're not careful it might even take more of your time.
No matter how good a programmer you are it is highly likely that you'll introduce a few bugs at some time. If you're diciplined with unit testing you can hopefully avoid bugs best possible. I highly recommend you to look into Test Driven Development (TDD) if you want to do your best for avoiding bugs.
There are several questions about unit testing and TDD on StackOverflow if you need help getting started. Here are a few of them:
不，大多数程序员的情况都低于 20%。
如果您想在游戏中取得领先，您将开始编写测试来配合您的代码。 Google for：
No, most programmers have it worse than 20%.
If you want to get ahead of the game, you'll start writing tests to go along with your code. Google for:
错误总是会出现，并且应该尽快解决，这样代码就在你的脑海中是新鲜的。
Bugs will always crop up and should always be tackled as soon as possible, that way the code is fresh in your mind.
例如，你可以写，但在你的帖子中存在一些“错误”：逗号后没有空格，逗号前有空格，点后没有空格，“程序员”不是某人的名字，所以最好是“程序员”。现在您可以用 20% 的时间来修复它们。
For example you are able to write, but in your post there are some "bugs": no space after comma, space before comma, no space after dot, "Programmers" is not a name of someone, so it's better "programmers". Now you can use 20% of your time to fix them.
这是一个奇怪的问题。如果我可以冒昧地重新表述一下......
首先集中精力不要制造它们。您可以采取许多措施来最大限度地减少错误：
随着经验的积累，您会发现简单的错误变得越来越少，而困难的错误（通常是由于库中的不良设计或未知行为造成的）开始消耗更多的时间。
It's kind of an odd question. If I may take the liberty to rephrase it...
Focus your energy on not making them in the first place. There are many things you can do to minimize mistakes:
As you gain experience, you'll find that the easy mistakes become less frequent and the hard ones (usually resulting from poor design or unknown behaviors in libraries) start consuming more of your time.
修复错误是编程的一部分，无论你喜欢与否，它都会永远存在。
只要编程存在，它就一直存在，并且会一直存在，直到我们不再编程为止。
它非常常见，您可以在许多常见的编程笑话中找到它。
和 Wayne 一样，大多数人花费超过 20% 的时间进行调试。
就我个人而言，我认为调试使编程变得有趣，不是因为它本身很有趣，而是因为你需要很长时间才能修复它，一旦你修复了它，你就会有一种压倒性的感觉，所以“哇哦！我做到了！”
再次，我同意韦恩尝试这些编程技术的观点，但是，它们剥夺了编程的所有乐趣。
我发现调试时有用的一件事是休息一下，然后在几分钟后返回代码，最好是在与朋友简短交谈或打个电话之后，您会惊讶地发现错误的速度有多快，最困难的部分是获得停止编程并休息一下的意愿。
Fixing bugs is a part of programming, whether you like it or not, it'll always be there.
It's been there for as long as programming has been around and it'll be there until we program no more.
It's so common you can find it in many of the the common programming jokes.
And like Wayne, most people spend a lot more than 20% of their time on debugging.
Personally, I think debugging is what makes programming fun, not because it's fun per se, but because it takes you so long to fix and once you've fixed it you get this overwhelming feeling so "WOOHOO! I did it!"
Again, I agree with Wayne on trying those techniques for programming, however, they take all the fun away from programming.
One thing I found useful when debugging is to take a break and then come back to your code after a few minutes, preferably after a short conversation with a friend or a phone call, you'll be amazed at how fast you can spot bugs, the hardest part is getting the will to stop programming and taking a break.
不，您不必必须花费 20% 的时间来修复自己的错误。
没有人提到任何有关 PSP/TSP 的内容，但减少错误修复时间正是 PSP（个人软件流程）的全部内容。通常，通过将设计文档和设计规范化，它可以使人们从一开始就将错误修复时间减少到 10% 以下。根据清单进行审查；标准化您的代码，也根据代码审查清单进行审查；然后进行编译和测试。
最终，您可以将错误修复时间减少到接近零，因为您可以更好地审查设计和代码。基本思想是修复设计文档中的错误或检查代码所需的时间要少得多；比在单元测试中查找和修复错误所需的时间要多，而且比集成测试还要多。
如果你使用良好的设计审查、代码审查和单元测试，你的错误修复时间几乎每次都应该低于 10%，我平均低于 7%（根据我的统计数据）。
No, you DON'T have to spend 20% of your time fixing your own bugs.
Nobody mentioned anything about PSP/TSP, but reducing bug-fixing time is what PSP (Personal Software Process) is all about. Usually it enables one to reduce bug-fixing time to less than 10% right from the start, by formalizing your design documents & reviewing them according to a checklist; standardizing your code, reviewing it according to a code review checklist too; and then proceeding to compile and test.
Eventually you reduce your bug fixing time to near zero percent, as you become better at reviewing your designs and code. The basic idea is that it takes alot less time to fix a bug in the design document, or by reviewing the code; than the time it takes to find and fix a bug in unit tests, and more so than integration tests.
If you use good design reviews, code reviews and unit-testing, your bug-fixing time should be below 10% almost every time, I'm, on average, below 7% (according to my statistical data).