< reading notes > Software debugging: The core of the problem-diagnostics

Statement: The content of this document is mainly from the book "Software Debugging the way of cultivation", Paul Butcher, belongs to the reading notes.

Don't rush!

Although you can use a variety of tools and techniques and the software itself to find defects, but your most important asset is your wisdom

• A debugging method

Hypothesis----design experiment--the assumption is not tenable, start again

• Using different types of experiments

There are several different types of experiments, but each experiment must have a clear goal. such as the internal running state of the software, the input parameters of the software, encoding logic itself.

• Experiments must play a role in validation

Experimentation is a means of achieving purpose, not an end in itself. Experiments can be used to prove or disprove assumptions.

• Make only one change at a time

One of the rules of the design experiment, you can only make one change at a time. This rule applies to any modification, so it is surprising that the rule is often overlooked! Although a few places in a single modification seem to save time, you may actually get only invalid results. Don't make this mistake again.

• Record the debugs you've done

In the long run, because of many experiments, you may end up forgetting what you did and wasting time on proven issues, or even getting into a blind alley. Therefore, the debug record should be done, ideally, each experiment will eliminate some of the possible causes, and ultimately find the root cause.

• Don't ignore any details

What you do not understand is a potential flaw, so even inexplicable phenomena are often very valuable in discovering the problem itself. Figuring out unexpected health conditions can save you a lot of time tracking down defects.

Related policies

• Inserting piles

Pay attention to Heisenberg's law, which itself should not affect the operation of the software itself, there is ample use of the insertion of piles left in the code, thus writing out of debugging software.

• Divide

In other words, this method can eliminate many wrong situations and improve efficiency, but it is not the only way to reduce the workload and improve the efficiency.

• Using Source Control Tools

Using the source control system, you can perform effective regression tracking, which can effectively tell you which changes are causing these problems.

• Focus on differences

Is the problem reproduced only in a specific environment? Are you re-entering a large number of data inputs?

• Learn from others

Many defects exist only in the code, so only you and the collaborators can solve them. But sometimes it's designed to specific algorithms, library files, and so on, which may have been the same for others.

Trap

Here are some of the hard-won lessons from the actual combat

• Did you make the right changes?

If the changes do not have any effect, then you do not change to the idea. The trap is easy to fall into and confusing, and the only defensive measure is to be vigilant at all times.

• Validation assumptions

Imagine a blind spot, to understand what assumptions you are making, and when to rigorously test it.

• Multiple causes

This is a difficult situation, and the most productive way to solve multiple-cause defects is to isolate the problem and find a way to reproduce the defect. Another way is to look for other obvious flaws in the same region and deal with them.

• Quicksand

The empirical approach is based on the ability to reproduce the problem one time and get the same results each time, but without this certainty, it becomes extremely difficult to achieve improvements. If you encounter this kind of problem, then stop immediately, continue to proceed will only get into bigger trouble. The main goal at this point is to find exactly what is changing so that you can control it.

Thinking Games

Debugging is hard, sometimes simply miserable, do not lose heart, we have met. This is part of the software development effort, and if you are in this situation, the following tips will help you solve these problems.

• Spectator Debugging Method

One of the most effective strategies is to ask people for help, and people are more powerful, and problems can be solved quickly. People who have done this work know that the simple act of explaining the problem once again can inspire inspiration. So I can not find people, to the rubber ducks or paper people are able to do.

• Role Playing

Useful in interpreting and discussing problems, especially when it comes to data interactions between systems.

• Change hankered

When you become depressed or overloaded, take a break and look at the angle of the problem may be very different.

• Make some changes.

When you're in trouble with an empirical experiment, it's necessary to make a little change, and any change can and will not tell you anything, but sometimes it surprises you.

• Sherlock Holmes principle

When you have ruled out the impossible, no matter what is left, he must be the truth!

• Insist

In despair, remember there is always a way to help you solve problems, as long as you have enough time, enough energy and determination, you will solve the problem.

Verifying diagnostics

We humans are versatile, one of which is self-deception. Taking this into account, it is worthwhile to take the time to verify your diagnosis.

• Tell someone about your diagnosis

They may find a flaw, even the bystander effect, that can help you achieve this effect.

• Check Source original copy

Re-verify your thinking when programming from a version that is known to have no problem.

• Discuss more with others

If you are wrong, do you know what mistakes you have made?

< reading notes > Software debugging: The core of the problem-diagnostics