Basic software debugging skills

Reading and programming, extensive understanding of knowledge and ideas in various fields, and occasionally inviting people to climb mountains, browse scenery, and attend seminars. In fact, life can also be very elegant. There has never been a boring life, but you don't have to take the initiative to look for life and discover fun.

Debugging, adjustment, and testing. Mechanical engineers usually need to set the instrument parameters for better observation. Software Debugging has a similar meaning. For example, senior engineers will set some parameters to achieve better performance optimization. In general, debugging usually refers to adjusting and correcting unexpected States to bring them to the expected state.

I have learned a little about software debugging and put forward it for reference.

1. Early Stage: focus on internal practice and train the problem analysis capability

It is recommended that beginners do not use any debugger when programming. They only use print statements. The debugging efficiency may be a little slow, but it can train a person's problem analysis ability. Instead of worrying about tools, I analyzed the program status and figured out what went wrong. Place the print statement where possible, run the statement, verify that the guess is correct, and gradually narrow down the scope until the problem is found.

2. Early Stage: sensitive evidence capturing

For large-scale applications, many open-source or closed-source frameworks are used, and a large number of exception stacks are often involved in errors, which is confusing. In this case, you can view the exceptions related to the Business Code in the exception stack, because the Framework Code is usually error-free and may be a problem with the Business Code itself, it may also be caused by incorrect understanding of framework APIs.

3. Middle Stage: Use debugging tools

Entering the real software development environment, you will find that many people are very efficient in using tools, which is very red-eyed. You can use tools to improve development efficiency!

For debugging, you must first learn how to use breakpoints. The breakpoint is similar to the print statement mentioned above, except that the print statement needs to be inserted into the program, and the breakpoint does not need to insert additional print statements. The program stops running here. In this case, you can check whether the Status values of each variable are correct. Single-step debugging may be used. setp into is required when a function that may have a problem occurs, and step return is recommended for a function that does not have a problem. This is basically the case.

4. debugging beliefs

No matter how strange the phenomenon is, there is always a reasonable explanation behind it. You just need to find out. Some of them are framework interaction issues that may be puzzling. For example, if a string parameter is input in the flex as function and the value can be printed, it is obtained as null on the Java end without any operation in the middle, which is totally a problem of interaction between flex and Java. It is strange that other similar calls successfully pass parameters. The only suspect is that the input parameter is from ComboBox
Is the child node of the XML string. It must have been a problem with the interaction between ComboBox, XML and Java.

VaR selitem = statusdata. selecteditem;

Alert. Show (selitem. book_id); // you can print the value of selitem. book_id on the as terminal.

Vmflex. dosomething (selitem. book_id); // pass in to Java to obtain null

VaR book_id: String = statusdata. selecteditm. book_id as string; // thought of a way to bypass

Vmflex. dosomething (book_id); // right

5. Hot debugging

Many things need to be pre-deployed for hot debugging. The so-called "Hot debugging" means that some modifications can be quickly fed back without the need to re-compile and deploy the entire project. Such as flex. I first came into contact with a project, such as flex, Java, and spring integration. I was lazy and didn't configure hot debugging. Even if I changed the result, I had to re-compile all the modules, although an automatic deployment script was written later to enable concurrent operations, the inefficiency of flex debugging took a lot of time. This also shows that,
To do well, you must first sharpen your tools.

6. Detailed log output

Detailed log output is also an essential tool for software debugging. It can be divided into four levels:

(1) Error Log: records program running errors. It is essential.

(2) Information logs: it is also important to record important operations, such as operations that lead to status changes and information returned by API calls.

(3) SQL log: records the executed SQL statements for future Query

(4) debug logs: usually not used. In rare cases, some valuable clues may be found. Optional. If the program performance is affected, remove it.

Log error output requires not only technical stack information, but also business information. When troubleshooting, you not only know which method has an error, but also the specific business and the Business Objects involved that have an error, so that you can easily compare and troubleshoot the problem. In addition, the time information in logs sometimes becomes an important clue.

7. If possible, start with the database

If you have the permission to access the database, you can start with the data to check whether the data in the database is correct. In this way, you can eliminate the problems caused by the data and determine that the problem lies in the program. If there is a problem with the data, first, we need to trace the cause of data inaccuracy, and then locate the program problem.

8. Single-step debugging

For hidden problems, the results of one-step debugging are surprising: Unexpected causes. For example, I worked well before debugging a code that calls an API, but after some modifications, I reported an nullpointexception exception. Read the program carefully and find that there are no obvious logical errors. Finally, we had to perform single-step debugging and quickly found the problem: it was caused by a null character problem. In another example, we inserted data into the database, verify that the database already exists. The error "nonexistent" is always reported. Read the code carefully and execute SQL directly in the database.
Both indicate that they exist. I was puzzled. Later, I used single-step debugging and found that no data was found when the application accessed the database through the service automatically injected by spring.

9. Comparison Experiment

Sometimes, some of the same business reports errors, and some do not. At this time, you can do some comparative experiments to analyze the differences and find the reasons. For example, if the database connection is recently closed by proxool. After detailed log output, it is found that ABC is worth noting in all clusters. AB reports an error while C does not. A, B, and C all have the largest number of database tables in the cluster, with millions of records. Later experiments showed that it would take about 10 minutes to execute the same SQL statement, A and B, and C only needs 9 s.
Left and right. Consult the DBA to learn that the query speed is slow due to limited memory size of A and B, and the database connection may be closed due to query timeout.

10. debugging in specific development fields

Debugging varies in different development fields. Such as frontend and backend, PC, server, and mobile device programming, system programming, and application programming. You need to learn some specific debugging skills for your development field.

11. reflect on and find out weaknesses

If some bugs are difficult to find out the source of the problem, we 'd better record it and review it for a while. What types of problems are difficult for you to find and solve? Are there any special methods for troubleshooting such bugs? For me, the issue of framework interaction is tricky. You must go deep into the framework source code to find the problem.

12. Framework Interaction Problems

The problems involving framework interaction are often tricky. The initial method is: source code + key breakpoint + single-step debugging + bold speculation and positioning + verification + patience. For details, see multi-data source dynamic configuration, loading usage, and framework interaction debugging.

By doing the above, most problems can be quickly located. Further, I am afraid that only the source code of the framework can be thoroughly explored or the experts can give you some advice. I have not done this yet. Let's talk about it later.