Programmer breakout-program debugging analysis (1) my insights from cainiao Evolution

Programmer breakout-program debugging analysis (1)

My insights from cainiao's evolution

Before talking about program debugging and analysis, we still understand some basic conceptual things (now we are engaged in Java, so we have taken Java as an example)

1. BugCategory

According to the program stage and the analysis of msdn and some books I have read, bugs are divided into compilation errors, runtime errors, and logic errors.

(1) Compilation Error

Generally, when a beginner makes many mistakes, the compilation is incorrect. To put it bluntly, the program is compiled from Java. A problem occurs in the class file. This problem is obvious. For example, if there is a problem with statement writing, what is the solution to this problem, turning over the API (reading the API and source code is a very important capability.) This is a convenient solution.

(2) runtime error

A running error occurs when the program is running. after the class file is loaded into the memory, a problem occurs when it starts to run. For example, the NULL pointer is abnormal, the class conversion is abnormal, The method does not exist, and the class cannot be found. How can this problem be solved, this requires classification. For example, the framework level is adopted, for example, the company's internal framework or third-party framework. For this type of framework, I can only say that you ask the company's Daniel to access Baidu on the Internet, the issues that can be searched out are all minor issues. Here, we recommend a relatively good foreign technical website, stackoverflow, a very professional technical website, and programs written by myself at non-framework level, check the log or errors printed on the console. Generally, you can find the answer nearby. If you cannot see it at a glance, set a breakpoint near the error location to check the values of the associated variables.

(3) logical errors

What is a logical error? Simply put, the Code does not follow the process we want to go down. The phenomenon is that the code compilation is normal and there is no running problem, but the desired result is not obtained, I often hear a few words like this: Why can't I execute my code here? Why can't I put my parameters in it? Why does the database remain unchanged after I modify the database.

What are the solutions to these problems? First, let's listen to the things I 've shared below, and you may feel a little bit better.

2.Debugging principles

(1) core principles: Understanding requirements

Everyone is always listening to others. You can help me see what went wrong here. For simple demo types, I usually know what went wrong, but it is a complicated problem. Can you solve bugs directly for others without knowing anything? Unless these bottom layers or things become simple, I think in most cases, we still need to understand the business scenarios, that is, the requirements and requirements in this aspect, this method includes business requirements and code writing, and even the implementation requirements. We may not need to know the business requirements, but the requirements at this encoding level, in fact, we need to know the real trend of our business data flow and actual code flow.

(2) core principle: positioning bugs, that is, narrowing down and eliminating irrelevant code

For simple bugs, you may know that You can debug them directly in the vicinity and check the relevant variables. This is indeed a very common method, but for a large functional module or even the whole system bug, can we see the bug at a glance? This is like a haystack, but how can we get a needle in the sea? Using core principle 1, after we understand the requirements, we can locate the problem, that is, the overall process of business data flows and code flows opens a gap, that is, the upper and lower boundary problems are fixed.

(3) I can't believe what he said. It's okay.

During work and study, you can always encounter a problem that someone else says. He describes a bug to you (fulfilling our principle 1 ), but when he described it to you, he often said this sentence. I did it according to his statement, but there was no expected result.

Here, what can we trust, that is, what he says, what does it mean, and no result he wants? is the prerequisite that he says credible, here, 99% is untrusted. Why is it not completely untrusted? We cannot deny that there may be bugs in the framework we adopt. to prevent us from submitting a wrong premise, we need to convert untrusted conditions into trusted conditions. How can we convert them? Here we can directly adopt the debug form, at the end of the article, we set a breakpoint to check whether the expected result is correct. If not, it indicates that the prerequisites are incorrect. Based on actual personal experience, generally, there are problems with the prerequisites.

3. BugDebugging skills

The bug debugging skills should be classified. First, let's talk about general purpose, and then perform specific implementation and operations on general purpose.

(1) debug

In the debug mode, you must learn. In the early stage of program learning, you should not only learn how to write code, but also learn how to debug, that is, stop the program to a breakpoint and stop it from going down, we can choose whether to let the program be executed step by step or all. During the execution process, we can also see the value of the relevant variables and their changes.

(2) Duck/teddy bear debugging

This method is also commonly used. In fact, you have used this method in ordinary times. When you describe the problem to others, you suddenly find the problem, we didn't pay much attention to this method. Because we usually communicate with others at home, we actually communicate with others and face whether they are busy or not, it is not important for us to communicate with people. We want to explain our logic again. So we can choose to talk to the pets next to us first. What should we do, when you think about the explanation of the duck/teddy bear, you will find that your thoughts, views, ideas, and actual code are deviated, so you find the bug in the code.

Once a problem fully describes its details, the solution is obvious. Maybe you think this method is too stupid and too mentally retarded, but this is a very effective method, this is the prototype of code Reviev.

(3) Java debug

Before talking about Java debug, you can have a basic understanding of DEBUG. What do we want to see about the debug mode? Data changes, program trends, and data changes are reflected in what areas? In the window of variables, What is the program trend? We want to control whether the program is going one step or multiple steps, go to the specified position, and whether to enter the method. In this way, the general mode of debug for different programs is derived, one-step debugging (one-step debugging is divided into one-step debugging into the method, one-step debugging does not enter the method), and continues until the next breakpoint

Java debug is no exception. You can take a look at the debugging shortcut keys and write an example by yourself. try this method.

Note that Java can run in multiple threads, so we can also see that multiple threads are in debug at the same time, so we can choose which thread to operate.

(4) debug of JS

General in (3) the general characteristics of DEBUG described in, debug in JS cannot escape these points, but the shortcut keys are different, in fact, often written in Java System. we can also use alert for out or other methods in JS, but this method is not recommended because it will destroy the original structure of the program.

Firebug is a useful tool in JS. As I am used to chrome, firebug has never been used, so I won't sell it here. You can see that it is a powerful tool for debugging Js.

(5) HTML debug

You may want to laugh at me. How can you debug HTML? Currently, I use a lot of methods to add styles to tags. commonly used methods are to add borders or background colors, since there are not many users, we have introduced so much about html Debug. Please reply to me if you have any good methods, share and change!

4.Avoid bugs

(1) A method only performs basic operations without complicated logic control. Generally, the code of a method cannot exceed the width of a screen. The larger the amount of code in a method, the more likely logical errors are to occur and the amount of code in the method is too large, it will waste a lot of time to write this method.

(2) coding Test

Many people like to write a large module for testing. In fact, after writing a key method, we should test it. Using JUnit, we can do it without damaging the program, you can write the test logic.

5.Solution

Because of the different bug situations, our solutions are different,

Some bug solutions have been introduced in the bug classification. Here are some other ideas.

(1) Identify bugs in the console/log. If no content is found in the log or console, this is also a symptom.

(2) If an exception is thrown Based on the symptoms and based on business needs/program requirements, you can directly find the problem thrown by the exception. For exceptions that can be understood, or exceptions that are already familiar, it can be solved quickly. For unfamiliar exceptions, if it is a simple exception, you can find the vicinity of the Bug, sort out the logic, and explain the logic to yourself, try to find it. If it cannot be found after sorting, enable the debug mode. For the logic that is still not found, if it is a framework class, directly read the official documentation or search or ask Daniel.

 

 

Summary:

The top core of program debugging and analysis is a person with a good mentality and bad mentality. It is blocked to find the problem. If you cannot find the problem, remember to go out for a stroll, in fact, most of the time the problem is not a bug that you are trying to find in front of your computer, but when you go out, the answer is already in your mind (as for the reason, let's see <programmer's thinking training>)