To debug bugs like a professional.

　　Welcome to the collection. 　　When you encounter a very difficult bug, you might as well come back here to see ... Programming would have been a very elegant job, and programmers, too, should have been the kind of artists who consistently write highly ornamental and creative work. Since then, however, the programmers around us have been caught in the mire of rushing to the exits and fixing the emergency bugs. You can often see the following scenes: · 　　Fixed a bug, but introduced a more lethal bug   constantly modify the code, restart the server, the bug is still not repaired   patch hit up, the bug still exists, positioning for a long time, finally found that the patch hit the wrong place 　　While we should be as sure as possible that the fewer bugs are in the code submitted, the better, but when the bug really appears, we are often very flustered, like a headless fly, the process of debugging is haphazard. 　 　Until recently happened to see this book--"Debugging nine Law", this is the first book I read about debugging methodology, I think of myself in the resolution of the bug often encountered in the helpless, like headless flies generally around, and finally the Blind cat ran into a dead mouse to solve the bug, I did not hesitate to buy the book. 　　This is a set of system debugging theory. 　 　I hope this article introduced this set of debugging knowledge, can help you in the future when you encounter bugs, thinking more clearly, the mood more calm, leisurely to solve the problem. 　　Debugging rules Overview This set of methodologies can be summed up in a sentence: Debugging is a science, any do not understand the principle of the operation is bullying. This sentence can be divided into two steps to practice: preparatory work: · 　　If you want to debug the system, first you have to understand it.   Check the "plug" Before you start debugging, and don't get busy doing it for a few simple questions.   OK, you need to reproduce the bug after you have no problem with the plug. Find the cause and solve bug   Don't think the reason you're guessing is right, observe, and verify your guesses.   adopts the divide-and-conquer method, locates the system problems of multiple modules and fixes the problems caused by multiple child problems.   Only one place at a time   do well 　　 Modify Records   If you are debugging, you might as well try the reverse debugging method   The last resort: Help others face these laws in detail. 　　Understanding System understanding system is a prerequisite for locating bugs. Before I encountered a program to throw an exception, often the exception information posted to the Internet search, and then the online solution to carry out, sometimes work, on a good luck, but most of the time, is not work, the reason is very simple, perhaps the other side of theJDK version is not the same as yours, maybe you two are just the same error message, but the reason for throwing exceptions, more likely, the other side of the solution is not feasible. This will understand why understanding the system is a prerequisite for locating bugs, if you are locating a JDK exception, then at least you have to master the Java SE, if you can master the garbage collection principle of the JVM, class loading mechanism, naturally better; and if you're positioning a payment system, why don't you hit the customer's account? 　　Then you have to understand the process of payment. In short, before we start debugging, we have to figure out that debugging is a science, not a probability, and you need to understand the whole system to be able to debug. Here are some ways to help you understand the system:   Reading manual: Reading requirements design documents, product documentation, use manuals, etc.   carefully read every detail of the manual: Maybe the solution to the bug is in a paragraph   MASTER the basics: Finally you always have to look at the source. , at least you have to master the appropriate programming language to   understand the workflow: from the perspective of the whole, rather than a frog in the well can be said that the ultimate goal of understanding the system is to understand the workflow, understand the workflow, you can see from the overall perspective, or like a frog in the well, Think the problem must be in your own module, but in fact the problem is in the upstream of a module. 　　 This, as mentioned in the programmer's thinking practice, coincides with the idea that experts think collectively. Check the plug here, of course, is not to let you ask the other people plug, plug in here is a general term for the basic requirements of the normal operation of products. 　　These basic requirements are usually considered normal by us, but they are sometimes not true. 　　For example, one of your systems, you need to configure a white list in the configuration interface, or upstream request will be rejected, then when there is a problem, you should first check the white list configuration is not, because the other side may be a novice. 　　Even when there are some unreasonable errors, you have to go to the software's running directory, such as Tomcat's WebApps directory, to see if the package is complete. 　　When you replace the new code and find that the bug is still there, go up and see if it's running, whether it's old code or not. The book puts this rule in the bottom three, I put it here to the second, the reason is very simple, usually we find bugs or others tell themselves there is a bug, the heart Will panic, will be nervous, so may wish to check the plug, ease the tension of their feelings, but also forced you from the overall perspective of the observation 　　 is not confined to a small module. Recurring failure This is almost a subconscious action, even if you have not read the book before, when you encounter a bug, you will try to reproduce it, for the simple reason: ·  Recurrence failure allows you to observe contextual information at the time of failure, and then to find out why the failure   The recurrence failure allows you to determine if the problem has been fixed and some of the problems are well reproduced, but some of them will only appear in the case of specific input. Most of the mistakes we make are in the way of reproduction, the author proposes two principles for:   to simulate failure, but do not simulate failure mechanism, because you think the mechanism of failure is likely to be wrong. For example, you think that a high concurrency-induced bug so you simulate high concurrency, the problem recurs, and then you say it's high concurrency, but it's just that high concurrency increases the likelihood of a problem happening.   only affects the frequency of errors and does not affect how the error occurs. 　　 In fact, a high concurrency environment can be used to improve the frequency of errors, but you want to reproduce the problem, to find the appropriate log information, and then locate the cause of the problem, rather than directly think that is the result of concurrency. 　　Do not guess, to observe now we can reproduce the bug, intuition tells me to make a string-coded conversion in that place, wait a minute, before making this arbitrary attempt, let's take a look at what Sherlock Holmes says: The judgmental person always distorts the facts for the sake of applying the theory, rather than explaining the facts in theory. Guessing is just to determine the focus of the search, but before you start the fix, watch to confirm your guesses. 　　So before we modify the code, or look at the error log information, you can debug the code, when necessary to open the source code in-depth study, to determine the problem is really string coding, and then to modify the code. Some people say, then I directly change the code, and then see the results do not know whether the string coding problem. Of course not, to know that a problem can be caused by a number of local code, perhaps to solve the problem of string encoding, but also need to solve another problem, in order to solve the whole problem. 　　If you do not observe before the modification, you will think this change is meaningless, so the whole debugging process will fall into Siju. 　　 Remember, debugging is a science, and any operation that does not understand the principle is bullying. Divide and conquer systems are usually composed of many modules, which requires us to check the log of many modules to determine the cause of the problem. 　　Especially now the popular micro-service framework, a business problem, you need to go to a number of service machines to find logs. However, if your business execution is linear, that is to say, if Node A fails, then node A will fail, then you can use the binary method to locate it. 　　You know, to guess a number from 1 to 100, it takes up to 7 times. Using the method of the second division, you will gradually narrow the scope of suspicion, and ultimately findTo the root cause of the problem. 　 　Of course, if the problem is caused by multiple child problems, remember to find one and eliminate one, which is called Divide and conquer. 　 　Modify only one place at a time by observing, you think your method of modification will work, but if you actually do not have any effect after modifying the code, then please change back immediately, lest this modification introduce a new bug. 　 　Make a record of your changes in the process of debugging the operation and results in order to record all of them, so that you find that you have done so many changes still do not solve the problem, to backtrack, reflect on their own operation there is no wrong place. The debugging rules on the reverse debugging method are all starting from the problem and looking for the wrong code. 　　But sometimes the converse may be better. 　　 You can find the latest version that works, and then compare the difference between the current version and that one, and analyze the changed code to see which code is causing the problem. 　　Sometimes it's more urgent to ask for help, so it's a matter of asking an expert, as the programmer's thinking practice suggests, experts rely on intuition, and they tend to give you a point on the spot. 　　If you have a certain understanding of the system, you can go to the software supplier's website, Google, StackOverflow and other sites to find relevant information. 　　In the process of seeking help, you only need to describe the symptoms of the problem, if the other party does not ask, then do not tell him his own theory, so as not to bring the other side into their own thinking. 　　 You may also be inspired to describe the problem to others. Summing up the above is that I read the "Debugging nine Law" after the summary of a set of debugging methodology, of course, or suggest that you look at the original, perhaps a new harvest. 　　However, the book listed a large number of examples, many let me feel some redundancy, suggest you see, first look at the beginning of each chapter, and the end of each chapter of the small summary, after reading there are not understand, and then to see the middle of each chapter of the case. Although most of the examples in this book are about engineering, there are some ideas that can be used to learn from life. 　　For example, the husband and wife Quarrel, the appearance is because the husbands do not want to wash the dishes, but if you can look at the overall point of view, you know, in fact, because the husband Valentine's Day did not buy a gift for his wife. 　　Look back on these rules, in fact, we are in the work and life, but we use it from time to time, but we have not a systematic theoretical system, in the book described in the debugging rules, we in the future to locate the source of the error, will be more organized and leisurely. Finally, it must be said that professionals should be in the development of the software as far as possible to ensure the quality, rather than often rely on debugging to make up for defects. Perfect and sufficient unit test is the key to ensure code quality. When you find a bug, it also means that your test case is not complete,After fixing the bug, try to fill in the test case in time. If you have any questions, welcome to add QQ Group Test introduction Great God 755431660 study together ~