12 key steps for bug fixing

Boss: So, how long do you need to fix this bug?

Inexperienced programmers: Give me an hour? A maximum of two hours? I can fix it right away!

Experienced programmers: How long will it take to catch a fish ?!

How long does it take to fix bugs? It is hard to know in advance, especially if you are not familiar with the code, the situation is even more confusing. In the art of agile, James shore clearly states that you must know where the problem is to be fixed. The reason why we cannot accurately estimate the time is that we don't know how long it will take to discover the crux of the problem. Only by knowing this, can we reasonably estimate the time required to fix the bug. However, at this time, I am afraid the daylily is cold. Steve McConnell once said:

"Discovering problems-understanding problems-this is part of the programmer's 90% job ."

Many bugs only need to change a line of code. However, if you need to invest a lot of time, you have to point out what is right-like when we are fishing, we need to know where to get bait and when fish are easy to get hooked. There are four types of bugs: the first is easy to find and fix, the second is hard to find and fix, the third is easy to find and the fourth is hard to find and fix. What is the most tragic is the last type. Not only is it "looking for, looking for, and looking for, cool, and cool", even if it is finally time-consuming, it can only be scratching your ears, instead, I sighed, "the road is long and the distance is long ". That can be said, unless it is a newly released code, it makes you look for a bug like a blind guy-confused, and do not know which type of bug you belong.

 

 

<! -- [If! Supportlists] -->I,<! -- [Endif] -->Search for and fix bugs

Do you know what "Finding and fixing bugs" mean? Yes, debugging! Continuous debugging and countless times of debugging! With a lot of work, Paul butcher summarizes the following structured steps:

1. define the purpose. Check the exception report carefully to identify whether it is a bug, identify various useful information to find the crux of the problem, and reproduce it. Check again whether it is repeated with the report. If the repeat occurs, let's see how the related personnel handled the problem.

2. Preparation-find out the correct code and clear the work area by division.

3. Match the test environment. If the customer is operating on the computer configuration, this process can be skipped.

4. define the purpose of the Code to ensure that all existing test tools are normal.

5. Now you can go fishing-reproduce and diagnose errors. If you cannot reproduce it, you cannot prove that you have completed the repair.

6. Write test cases or use existing test cases to capture bugs.

7. Go to repair mode-make sure that it does not affect any other part. However, you may need to undertake refactoring before you start the repair work, because only in this way can you tamper with the code without scruples. In addition, subsequent regression testing ensures that you do not add any new bugs.

8. Sort out the code. By performing one-step refactoring, your code is easier to understand and safer.

9. Ask someone else to review the information.

10. Check the repair process again.

11. Try not to start from the main line to check if these bugs affect other lines. Merge these changes, handle differences in the code, and review all reviews and tests.

12. Think. Think about what went wrong and why? Why does your repair work? Where else will this type of bug occur? In the book the pragmatic programmer, Andy hunt and Dave Thomas also pointed out that "if a Bug takes a lot of time, you must find out the cause ". In addition, we also need to think about how we can learn from our experiences and learn from other similar problems in the future? And, are there any improvements to our methods and tools? And the impact and severity of these bugs.

<! -- [If! Supportlists] -->II,<! -- [Endif] -->Which one needs more time to locate or fix a bug?

It may take much more time to build a test environment, reproduce problems, and test bugs than to locate and fix bugs. However, for a small number of obvious bugs, it is easy to find them-but it may be unsatisfactory to fix them.

In making software, a chapter mainly explores the source of most software vulnerabilities. Dewayne Perry believes that, compared with fixing, it takes longer to discover bugs (including understanding bugs and recreating bugs. Studies have shown that most bugs (about 3/4) are easy to detect and fix: 5 days or less (this is based on data from large-scale real-time systems that have passed heavyweight SDLC, massive review and testing ). But there are also disgusting bugs. Even if you can easily reach it, you still have to "Work hard" to fix it.

Discovery/Repair	Repair time <= 5 days	Repair Time> 5 days
Able to reproduce Problems	72.5%	18.4%
Difficult to reproduce or simply unable to reproduce	5.9%	3.2%

So if you bet that you can fix the bug quickly, in most cases, you are right. But when you lose your bet, it means you have a lot of trouble. By the way, we will introduce a good platform-devstore, source code download, and third-party services, which is very practical.

So next time, the boss will ask when to fix the bug. Don't say "you can fix it right away" in a dumb.

 

Original article: fixing a bug is like catching a fish Translation: codeceo-Xiaofeng

12 key steps for bug fixing