开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
今日推荐开源项目:《缩写 nbnhhsh》
今日推荐英文原文:《When Should You Give Up on a Bug?》
开源日报第750期:《缩写 nbnhhsh》
今日推荐开源项目:《缩写 nbnhhsh》传送门:GitHub链接
推荐理由:这年头,缩写是用的越来越多了,这玩意可以说是懂的都懂,那不懂的呢?都不懂。为了让那些不懂的人能够理解这种缩写语言,这个项目诞生了:它能把缩写转换为可理解的有可能的中文选项,如果没办法让所有人都hhsh,那就想办法让所有人都能ljlj就行了。
今日推荐英文原文:《When Should You Give Up on a Bug?》作者:Steven Popovich
原文链接:https://medium.com/better-programming/when-should-you-give-up-on-a-bug-cc546332b18
推荐理由:有些 bug 并不该被修复,如果花时间修复它们并不值得的话(比起那些更重要的事)

When Should You Give Up on a Bug?

Some bugs are just not worth the hunt

Programmers 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.

Conclusion

There’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!
下载开源日报APP:https://openingsource.org/2579/
加入我们:https://openingsource.org/about/join/
关注我们:https://openingsource.org/about/love/