Jun 01, 2021 Article blog
1. Because the problem report's description of how to reproduce is very vague.
2. Because the reported problem is related to a feature, I'm not familiar with it.
3. Because I spent a lot of time investigating the real cause of the problem, not just the surface.
5. Because I took the time to verify that other parts of the code were affected by similar problems.
Ming Ming only added two lines of code, why did it take two whole days?
This question may seem reasonable, but there are some terrible assumptions behind it:
But none of this is true.
It took someone a full two days to change the code, but why do we look back and think it's so easy?
(Recommended tutorial: python tutorial)
It took me several hours to successfully reproduce the problem. S
ome developers immediately go to the person reporting the problem and investigate when they have more information. A
nd I will try my best to use the information that has been provided. I
know some developers don't like bug
bug
so they'll try to get away with it. C
laiming that you don't have enough information is a good way to shake the pot in time, and it looks like you're trying to help, but you don't have to do any work. I
know it's very difficult to report errors, and I'm very grateful to those who reported them.
I'll make the most of the information I have, and I can't really ask anyone who reported the error for more information to express my gratitude.
I rarely use features related to this issue, and I have not been exposed to specific details related to this feature. So I spent a lot of time understanding how to use this feature and how the bug interacts with the software.
If some code throws an error, you just wrap it in
try..catch
can be suppressed in catch statements. N
o mistakes, no problems. I
s that right? S
orry, in my opinion, hiding the problem is not the same as solving the problem. M
asking errors can easily lead to other unexpected side effects.
I don't want to stay in the future and deal with them again.
Errors can be easily surfaced through a set of reproduction steps, but in reality they can involve deeper problems. F ind the exact cause of the problem and study all the ways to solve it to provide valuable insights. For example, the actual use of code, there may be problems to be solved elsewhere, or there may be code inconsistencies that cause errors to be raised in one code path, while others will not.
If an error causes the
bug
the same error may exist elsewhere in the code base.
I can take this opportunity to examine it carefully.
(Recommended course: JavaScript tutorial)
I don't want to fix the problem in the quickest way. I hope that fixing this problem will not cause confusion or other problems in the future.
I don't want to rely on others to test whether the changes I've made are correct. I
don't want to wait until I've completely forgotten about this change before I find a
bug
forcing me to look back at the code again. S
witching back and forth is time-consuming and frustrating.
I don't want a full-time tester to test the same change again.
I don't like the work of changing
bug
in part because it feels like it's the result of my previous mistakes.
Another reason I don't like bug
bug
is that I prefer a new job.
Q: What could be worse than changing bugs? A: Fix the same bug over and over again.
I'd like to take the time to make sure that every
bug
I encounter is completely fixed so that I don't have to face
bug
anymore, and I don't have to spend time investigating, fixing, and testing
bug
The above is about why sometimes clearly only added a little bit of code, but spent several days related to the introduction, I hope to help you.
Original: www.mrlacey.com/2020/07/youve-only-added-two-lines-why-did-that.html
Reference source: blog.csdn.net/csdnnews/article/details/107903206