It is no exaggeration to say that programmers may spend half of their time fixing bugs. Although, according to the 28 principle, most of the bugs can be found on search engines (except for business bugs), but the remaining 20% bugs often take 80% of our time.
Although the best way to solve this problem is to reduce the occurrence of bugs, but no matter how much it is reduced, it is impossible to reduce to 0. We still need to improve the efficiency of our Debugging.
Because in terms of Debug, a high-level person may lead at least an order of magnitude in efficiency. I have been in this industry for nearly 9 years, and I have seen too many such cases. There has also been a case with a high degree of spread on the Internet. There is an issue that has been unsuccessfully investigated by the internal team of Alibaba for several days. Ask the Lord Duolong, and it will be done in a matter of minutes.
In my opinion, there are two main reasons why many people's Debug ability has stagnated for a long time.
One is that I don't know enough about the functions of the IDE, and only use the basic functions that I have been using.
The second is that they have not mastered a reasonable debugging idea, and they are "luck-type" players.
Different programming languages, mainstream IDEs are different, so I mainly talk about my experience on the second point.
Some experienced programmers know that the most important thing in the debugging process is not how to fix the bug, but how to find the place where the bug occurs. Therefore, the ideas to be discussed below are mainly related to troubleshooting bugs.
/01 Narrow the scope of the problem/
There are many ways to narrow the scope of the problem. In essence, it is to find variables that are more relevant to the problem from the environment at the time. The most common variables are mainly in the following:
Operating environment
Operating data
browser
Corresponding source code version It is
recommended that you verify from these variables first. Then figure out what happened between the last normal operation and the current bug operation. In most cases, the root of the problem lies in it. The kind of difficult problems that have been hidden for a long time, after all, are rare.
/02 Refine and optimize the standard processing process for each type of bug/
Many processes in the work require SOPs, and you can also do the same for fixing bugs, so that the process of fixing a difficult bug every time can be precipitated.
There are mainly four common types of bugs:
output does not match expectations,
program reports errors,
programs are obviously slow in response,
program crashes
each type has their own troubleshooting methods, if you always use the same routine to troubleshoot these 4 types of problems, the efficiency will naturally be inferior. Will be too high.
1. The output does not match expectations
This kind of bug is the most troublesome, why? Because it is not like the kind of abnormal and error-reporting bugs, it has stack information, which can quickly narrow the scope of investigation, and even directly locate the place where it is generated.
So what to do? If the problem is in the test environment, it is the easiest to start with single-step debugging. At this time, if you master the IDE's debugging tools more deeply, the efficiency will be higher, such as condition variables, multi-threaded debugging, and so on.
One more sentence here. It is strongly recommended that everyone master the two methods of IDE condition variables and multi-threaded debugging. In the current environment, large-scale projects and multi-threaded applications in the entire software development field are higher than a few years ago. many.
If you can't step through the debugging, you can only use more logs to achieve the effect of single step debugging. However, this requires you to make some predictions. Just log some code branches and suspicious locations. After all, it takes time to write the code for logging.
2. The program reports an error
This kind of bug is the easiest for some experienced programmers, because it directly tells you the code location where the exception occurred.
But it’s different for novices. Many novices will search for a search engine with a bunch of text describing the exception, such as (NullPointer Exception), find out more than N articles, read one by one and try to find that they can’t solve their problem. , In fact, because I am not used to looking at the stack information. Because other people's NullPointer Exception and your NullPointer Exception have different causes.
The entire call chain is recorded in the stack information, so you can see the complete method call sequence here.
However, it is worth reminding that in daily code writing, you must not try to catch the code block at will, and then throw a new exception, because this will cause the stack information to be incomplete.
3. The program is obviously slow to respond
This kind of problem generally occurs when resource competition occurs or when resources are tight. The difficulty of investigating them is also relatively high.
If the difference between the high-level and the low-level of the first two types of problems lies in the level of efficiency, then this problem may be that for low-level programmers, no matter how much time they spend, they can’t find the cause of the problem.
But it does not matter, I suggest that you encounter this situation in the future, and give priority to the following indicators.
Number of TCP connections
Memory usage Number of
threads
For TCP connections, you have to keep a copy of the netstat command manual by your side, and then type in the commands to check whether the number of connections is close to 65535? Are there too many connections in the TIME_WAIT and CLOSE_WAIT state?
In most cases, there are two main problems related to TCP connections: the
connection is not released in time after the connection
is used up. The long link is not used for high-frequency calls, but the short link is used. At this time, once the downstream service responds slowly, 65535 connections will be quickly filled.
The analysis of memory problems is mainly carried out by analyzing GC, focusing on whether any types of objects occupy too much memory. If there is a situation that is too large, the main reasons are the following two:
a large object should be shared for use, and each instance is accidentally written in the code.
When an object was allocated, the static keyword was accidentally carried, causing the GC to be unable to reclaim the memory allocated for it.
Different programming languages have different GC analysis tools, which require proficiency.
The analysis of threads, similar to TCP connections, mainly focuses on the number and status of threads. It is not that the more threads, the better the performance. The greater the number, the more time spent on context switching between threads than the actual execution of code logic.
In addition, is there a large number of threads blocked or deadlocked? Just pick one of the threads and analyze its current stack information, which is the problem.
4. The program crash
There are two main reasons for the crash:
the reason 3 mentioned above is not detected in time, which causes the program to run until the resources are exhausted, and the operating system intervenes to forcibly terminate the operation.
There is an uncaught exception in the code.
For the first point, refer to the treatment of Cause 3.
The second point is very simple. Make a big try catch at the outermost layer of the code, and then log the stack information and post it online. You can naturally see where the problem occurred, and then go to the cause. 2 processing methods.
Finally, it is necessary to practice more to improve the Debug ability. Therefore, I highly recommend that you bravely initiate the task of troubleshooting online incurable diseases when conditions permit, even if you are not directly responsible for the functional modules.
It may seem to outsiders that you are helping others to "wipe your ass", but this will significantly improve your Debug ability, and it is easy to form a dependence on you, making you stronger and stronger.
Well, to sum it up.
In this article, Brother Z shared with you my views on improving Debug efficiency.
To improve the efficiency of Debug, one is to have a proficient understanding of IDE tools and know some high-level usage methods. The second is to have a set of ideas for Debug.
For the second point, the steps I suggest are:
1. Reduce the scope of the problem
2. Refine and optimize the standard processing process for each type of bug.
Bugs are mainly divided into 4 categories. The ideas I gave in the article also distinguish these 4 categories:
1. The output does not match the expected
2. The program reports an error
3. The program is obviously slow to respond
4. The program crashes.
Hope it can help you.
In my opinion, Debug is a very fun and fulfilling thing, no less than designing a project framework. And Debug also allows you to truly appreciate what "the devil is hiding in the details".