今日推荐英文原文：《When Should You Give Up on a Bug?》
今日推荐英文原文：《When Should You Give Up on a Bug?》作者：Steven Popovich
推荐理由：有些 bug 并不该被修复，如果花时间修复它们并不值得的话（比起那些更重要的事）
When Should You Give Up on a Bug?
Some bugs are just not worth the huntProgrammers are built to fix bugs. When we see something broken, we instantly engage the part of our brain that analyzes what’s going on and why it’s happening. We can quickly put together parts of systems in our head and reason about why something might be broken. We can nanovision to the spot in the codebase and quickly implement a fix.
And sometimes we can’t. Not all bugs are created equal.
Sometimes bugs are one-line fixes that can be fixed with little thought. Sometimes bugs require huge architectural changes. Sometimes it’s hard to figure out what’s actually happening.
Furthermore, there are bugs we shouldn’t fix. Fixing bugs takes a cost-benefit analysis, just like any other part of software development. Here are the factors to consider when deciding whether you should tackle a bug.
Is There a Workaround?Is a bug with a workaround a bug at all? When we have bug, users instinctively try to get around it. This is a major factor in whether you need to fix a bug quickly.
Let’s say a user can get themselves into a broken state with five clicks, but they can still get the desired results with 10 clicks. This is a workaround. The underlying issue still exists, but at least the user isn’t blocked in doing what they want to do. If a workaround exists, you don’t have as great a need to fix the bug.
How Hard Is It to Reproduce?What’s worse than a bug that’s hard to reproduce? Maybe it happens transitively (random chance), or maybe it happens in a state of the application that’s hard to get the app into (50 clicks of your mouse to get the app into the weird state).
When steps to reproduce are long, it can decrease the likelihood you’ll be able to fix the bug in a timely manner. So the harder the bug is to reproduce, the less likely that it’ll make business sense to fix it.
How Much of Your User Base Is Affected?If you have a user write in with a problem and you reproduce the bug and realize it’s a bug with only one user’s account, then the total impact of the bug is lower.
Maybe one user is a lot, though. If your percentage of users affected is high, it may be more important. But if it’s one user out of millions, then it may not be a big enough deal to drop everything and fix.
How Severe Is It?A bug also has severity. When the bug occurs, does some button change color? That’s not so bad. Or does the app crash? That’s worse.
Severity means how much of the user’s experience is impacted. If the app is still usable when a bug occurs, you may not need to move as quickly to fix it.
How Long Will It Take to Fix?A bug can sometimes be fixed with just swapping around some logic. But if a bug requires a major change, it’s more costly to fix.
If the bug requires the refactoring of large pieces of code that may or may not be tested, you may be less likely to fix it.
How Will These Evaluations Change?This is a sneaky one, and people seem to forget to factor it in. You can make all these evaluations, but how will these measurements change?
In a month, will this bug get worse? Do we expect it to start to affect more users? Will upgrading make it go away anyway? Will a workaround stop working at some point? If factors get more severe soon, you may need to move quickly to fix a bug.
ConclusionThere’s a not magical equation of whether you should fix a bug. It’s a cost-benefit analysis made with very soft factors that are hard to measure. It requires input from developers and business analysts alike.
It may seem wrong to not fix every bug in your software. Some people probably cringe at the thought. But bugs exist in the world of business and thus must be analyzed with a cost-benefit analysis. Some bugs just don’t make sense to tackle.
Thanks for reading!