Programmer orientation problem solving methodology

How to solve the problem faster ？

We're meeting bug When If you search every time you encounter a problem Break point debugging What progress have we made ？

If you encounter those that cannot be searched The problem of not being able to debug at breakpoints ？ Be a man , Think long term .

So we might as well cultivate a kind of thinking now , Discard breakpoint debugging , By guessing , List the problems first , Evaluate how long it takes to eliminate this problem , Then focus on doing .

We often fall into a kind of direct hands-on , Spend a lot of time solving problems , This certainly solves the problem , Also impressed , But the real harvest is not much , The key is that a lot of time is wasted .

Scene simulation

For example , Let's see such a scene .

I use redis Cached the data of the article , But why every time sql Query ratio redis Get faster ,redis Is there anything wrong ？

1. First of all, keep yourself low , Why did you encounter this problem yourself , Others cannot meet ？redis Something went wrong. ？ Can't others repair it ？ It happened that you, a stranger, found it ？ Where do you put those big guys ？

Then you can ask questions

1.redis There is a problem ？ probability 0.01%, I just found out the problem by this vegetable chicken , I'm going to mention bug On github.

2.redis The configuration is not written correctly ？ probability 10%, It used well before .

3.redis The data is full ？ probability 5%, Then why did I have problems in this investigation ？

4. The data I inserted is too large ？ probability 50%, I wrote so much .

5. Is there a problem with the method I call ？50++% , But you can have a little look , It's been a long time , Maybe the method is wrong .

A cursory list of these .

Then let's take a specific look , Slow check , The data is too big , But I print it out , Just a little data , How could there be a problem , But when I look at the visual interface , He said there was too much data , also \x00\x00\x00 The mess of ？

It's very contradictory , One is the large amount of data , One is to print it out well ？ Mixed \x00\x00\x00 What is it? ？

Let's go back to the call of that method .
As shown below

Oh , Sure enough, there is something wrong with the call , The third parameter is the expiration time , The result is an offset , As a result, many empty offsets appear in the data .

Now let's talk about different solutions for programmers who encounter similar problems .

The first level

A cavity of blood , Do it as soon as you think of any problems , Silly breakpoint debugging , It belongs to the first level , Is the level of junior programmers , The boss will never use this trick , Hurry to do it , It's a lot of people , Common diseases of people including me , Maybe this will impress you , But it will waste a lot of time , It doesn't have to be solved bug.

The second level

What is the phenomenon of the problem , What is the most likely probability , List these probabilities , And then arrange them in order of the highest probability , Check again , If not, eliminate , This is the second floor , Like those listed above, maybe , Evaluate according to your own feelings , When you rule out all possibilities , The rest is no longer true , That's the truth , Of course, you have to make sure that the problems that arise must be among the possibilities you raise , Extreme cases can be ignored .

The third level

Put the probability of each problem , The time to exclude is also listed , As shown below

1.redis There is a problem . probability 0.01% I just found out the problem by this vegetable chicken I'm going to mention bug Turn to source code ？ Exclude estimated time , Unknown ！！！！ A few hours You may not be able to find out the reason .

2.redis The configuration is not written correctly ？ probability 10% It used well before , Exclude estimated time ：10 minute .

redis The data is full ？ probability 5% Then why did I have problems in this investigation ？ Exclude estimated time ：1 minute .

The data I inserted is too large ？ probability 50% I wrote so much Exclude estimated time ：5 minute .

Is there a problem with the method I call ？ probability 50++% But you can have a little look It's been a long time Exclude estimated time ：1 minute .

Sum up , There's a high probability , Low time priority , First check the method call , Let's look at the reason for inserting data , Go up and eliminate , It takes much less time than interrupting , Because sometimes you may not know why you interrupt , Instead, a lot of time is wasted .

The fourth level

Someone asked , There is no fourth floor ？

Then I want to , It's the third level method + Breakpoint debugging ( Split debugging )+ Irregular reminders .

When we eliminate some problems , Breakpoint debugging may be used , There may be something wrong with some method , But a method contains a lot of code , Thousands of lines , Don't you watch it one by one ？

We identify a problem , Set a code scope for this problem , If you can't decide , Then you can try half of the interruption point , Two more points to narrow the scope , This also applies only to specific situations , Sometimes two points are not easy to use .

Let's fix a time for the error of estimation , such as 2 It'll be done in an hour , So it can be 15 minute , Half an hour , An hour , Set a reminder respectively , Is there a dead end ？ Have you been stuck on a problem for too long ？ Go for a walk , Clear your mind , Come back and solve .

For the time being, I only think of these layers , If there is a better way , Welcome to leave a message , I will add the fifth level later .

People who are pure good or pure evil do not exist , Like a smooth piece of paper . People have many facets , Like a folded piece of paper , To stand up steadily .