Chapter 23 debugging
Debugging
Debugging is the process of determining the root cause of the error and correcting it.
23.1 overview of debugging issues debugging Overview
· Role of debugging in the role of software quality debugging in Software Quality
Like testing, debugging itself is not an improvementCodeQuality method, but a method for diagnosing code defects.
· Variations in debugging performance debugging efficiency is greatly different
In addition to the huge differences in debugging efficiency, this study also confirms the general rule of software quality: improving software quality can reduce development
. BestProgramThe staff can find the most errors, find the fastest errors, and often correct the errors correctly.
· Defects as opportunities give you some gains
Errors in programs provide you with great opportunities to learn many things.
1. Understand the program you are writing.
2. identify the type of error you have made.
3. Analyze the code quality from the perspective of the code reader
You must read your own code to discover the defects. This gives you a discerning view of your code.
Quality opportunities. Is the code readable? How can it be better? Use your structure to refactor your current Code and make the code you program better next time.
4. Review your solution to the problem
5. Examine the methods for correcting Defects
Have you used a bandage like Goto or simply bandaged some special cases to cure the symptoms?
· An ineffective approach is an inefficient debugging method.
The dedevil's Guide to debugging
1. Identify defects by speculation
2. Do not waste time on understanding problems.
3. Correct Errors in the easiest way
Debugging by superstition superstitious debugging
Satan has generously rented a part of hell to programmers who complain during debugging. Every team has such a programmer who will always encounter endless problems: disobedient machines, strange compilation errors, hidden defects and invalid data that occur during the full moon, forget to make important changes, a compiler that cannot normally Save the program-How do you describe this behavior?
This is "programming by superstition )".
You know, if the program you write is not a problem, it is your reason, not a computer or a compiler. The program does not produce different results every time. It is not written by yourself, it is written by you, so please be responsible for it. Even if a mistake does not seem to blame you at first glance, it is best to assume that it is related to you in your own interests. In this way, we can avoid the embarrassment of accusing others of making mistakes in front of the public, but finally finding that the mistakes are actually caused by you.
23.2 finding a defect search
Debugging includes searching for and correcting defects. Looking for defects -- and understanding the defects -- usually accounts for 90% of the entire debugging.
· The scientific method of debugging scientific debugging method
When using classical scientific debugging methods, you will go through the following steps:
1. Collect data through repeated experiments
2. Construct A Hypothesis Based on the statistics of relevant data;
3. Design an experiment to prove or prove this hypothesis;
4. Prove or prove a hypothesis;
5. Repeat the preceding steps as needed.
Effective methods for finding defects:
1. Stabilize the error status; -- stability the error
2. Determine the error source (that is, the error "fault") -- locate the source of the Error
3. Repair defects
4. Test the repaired parts
5. check whether there are similar errors.
· Tips for finding defects in tips for finding Defects
1. consider all available data when constructing assumptions
2. extract test cases that generate errors
3. Test the code in your unit test suite.
4. Use available tools.
5. use different methods to reproduce errors
6. Use more data to generate more assumptions
7. Results of negative test cases
8. Brainstorm on possible assumptions
9. Put a notepad on the table and list the items to be tried one by one
10. narrow down the scope of suspect code
11. Be cautious with classes and subprograms with previous Defects
12. Check the latest modified code.
13. extend the scope of suspect code
14. incremental integration
15. Check Common Defects
16. Discuss with others-some people call it "regret-based debugging"
17. Leave the problem blank and take a rest.
· Brute-force debugging brute force debugging
When debugging software faults, brute force debugging is often ignored. "Brute force" refers to a method that may be considered boring, time-consuming, but ultimately ensures that the problem can be solved.
1. Set a time limit when "quick dirty debugging" is used.
For every brute force debugging method, your response may be "I can't do it! Too much work !". Every one of us is willing to use a high-risk method that may discover defects within five minutes, or half an hour for some way to ensure that they can be found.
If you plan to extract the fruits of victory through shortcuts, set an upper limit for the time you try shortcuts. If the time consumption exceeds the upper limit, it is necessary to honestly admit that the problem is more difficult to analyze than you initially thought, and you should start over the difficult road.
2. Make a list of brute force debugging methods
· Syntax errors syntax error
The syntax error is about to exit the historical stage, just like the swordsmanship and the hacker. The compiler is better and better at displaying diagnostic information. The following are some suggestions to accelerate the extinction of this rare species:
1. Do not trust the line number in the compiler information too much.
2. Do not trust the compiler information.
3. Do not trust the second message of the compiler.
4. Divide and conquer
5. Find unpaired comments or quotation marks
23.3 fixing a defect correction
1. Understand the problem before you start
The "Devil's Guide to debugging" is right: if you want to make your life miserable and make your code quality messy, the best way is to fix program defects without knowing how to fix program defects.
2. Understand the program itself, not just the problem
3. verify the analysis of errors
4. Relax.
5. Save the originalSource code
6. Governance, not governance
7. Make sure you have appropriate reasons to modify the code.
8. Only one change at a time
9. Check your changes
10. added a unit test capable of exposing the problem.
11. Search for similar defects
23.4 Psychological Factors in psychological considerations in debugging
23.5 debugging tools-obvious and not-so-obvious
Debugging tools-obvious and less obvious
· Source-code comparators source code comparison tool
· Warning message of compiler warning messages Compiler
1. Set the warning level of the compiler to the highest level, try not to let off any warning, and then correct all errors reported by the compiler;
2. Handle warnings with a wrong attitude
3. Use unified compilation settings within the project team.
· Extended syntax and logic checking enhanced syntax check and logic check
· Execution profilers
· Test frameworks/scaffolding test framework/scaffolding
· Debugger Debugger
Key Points
1. debugging is closely related to the success or failure of the entire software development. The best solution is to use other methods described in this book to avoid defects. However, it is very cost-effective to spend some time improving your debugging skills, because the gap between excellent and poor debugging performance is at least.
2. to succeed, it is critical to systematically find and correct errors. Focus on your debugging, so that every test can move you in the right direction. Use scientific methods.
3. Understand the root cause of the problem before solving the problem. By making a random guess about the source and random modification of the error, your program will be in a worse situation than it was when debugging started.
4. Set the compiler warning level to the strictest, and correct all errors reported by the warning information. If you ignore obvious mistakes, it is very troublesome to correct those subtle mistakes.
5. debugging tools are a powerful support tool for software development. Find and apply these tools. Of course, remember to use your brains during debugging.