The debug process is actually the process of constantly asking and answering questions to a rubber duck (yourself)
How do I ask a good question? - Help Center
First search our own Codebase and Slack, there are some issues we may have already solved in other projects or we have some discussions in Slack. both Git and Slack have authors or related people, which also allows you to quickly find someone to ask if you don't understand the issue.
Next, search for Github Issues or StackOverflow, or ExchangeOverflow. Be sure to check if the question is the same as yours. A good Github or StackOverflow question will definitely contain a good step-by-step reproduction of the issue, and you should compare these steps to see if the issue is consistent with your situation. Prioritize searching the pages of the technologies or libraries you use, as these are the ones you use and are more likely to be the same problem as yours.
In addition, technology blogs have a lot of good content, from the point of view of our problem solving, the content of technology blogs can be divided into two categories. One is to introduce technology, including sharing the principles and implementation of technology and the use of skills, technology updates, or future planning. One category is the introduction of their own problems encountered when using technology, as well as the investigation and analysis of the problem, which may include how they are solved. Because the content of technical blogs is quite long, you need some time to read and understand and identify whether the content is useful to us. When you have enough time to investigate, you can read the blogs slowly to absorb the knowledge. But if you need to solve a problem quickly, technical blogs are not a good source, because you may spend half an hour or more to figure out what the blog is saying, and then you find that it does not help you much to solve the problem at hand.
When you have a problem, if there is a log and an error message, you can search around the error message or error code. If there is no error log or if the error log does not print enough information, you can add more logs to print out the information you want.
When you get the error message or error code, DO NOT copy the error message or error code IMMEDIATELY to google for searching.
You need to understand the meaning of the error code and error message first. Figuring out the following things will help you locate and solve problems faster.
- which line of code is throwing the error
- which library the error is coming from
- why did we introduce the library or the technology
These can be answered by looking at the stack, and if the stack is not deep enough, you can try printing a deeper stack.
Error messages and error codes are all human-defined, and there are several more common categories:
- Error messages are assembled in our own code.
- Error messages assembled by third-party libraries that we use, in the code of the third-party libraries. (E.g. Webpack, serverless )
- Error messages are thrown by the third-party software we are using, in the source code of the third-party software, we are running. (E.g. Database software)
- The error messages defined by our runtime environment are in the source code of node or python or any other runtime we use. (E.g. Nodejs Unable to import module )
- The error messages thrown by the operating system used are defined in the Linux source code. (E.g.ENOSPC)
For different error categories, you need different knowledge to understand the meaning of the error. But in any case, you can find the code that assembles these error messages in the code, or you can follow the stack to find the conditions used to throw these errors.
When you figure out the significance of these errors, you should spend more time looking at your own code and why they are triggered. Because in most cases, we use the operating system, third-party software, the runtime has been reviewed by countless people and countless iterations, we can rely on them in most cases, the default they are bug-free. But of course, in some extreme cases is also possible for us to encounter rare bugs. As for third-party libraries, in most cases, these libraries come from the open-source community. You know that the quality of the open-source community for node.js varies, so be wary of third-party libraries, and it's best to read and audit the source code of a third-party library before introducing it.
Conclusion
- Print more logs or deeper stacks to get enough error information if you don't have enough error information
- You have to have a preliminary knowledge of what you are searching for, otherwise searching for whole sentences of errors is just a waste of time.
- When you don't know the meaning of the error message, learn the relevant background knowledge first and understand the meaning of the error message before searching
- Once you understand the meaning of the error message, you have a general idea of why you encountered the error, and it's time to search for more information to verify that your thinking is correct.
Most of the time we encounter problems that are not 100% the same as those in Github issues or Stackoverflow, so what we need to focus on is not the code of the solution they eventually post, but the discussion about the problem. Because the solution they give, which may only apply to their scenario, is not a universal solution. Sometimes they even give solutions with some trade-offs that lead to ugly or tricky solutions.
Sometimes the discussion of a question may be long, usually dozens of replies, and if it is a long time Issue may have several hundred replies. We don't have much time to read each of them carefully. So we should focus on the questioner's message and the relevant person's reply. For example, If this is a question about a third-party library, We should focus on comments from people who are familiar with the library, such as the authors or contributors of the library. If it is a third-party software, we should focus on the more active participants in this community, or on the responses of people who have the same usage scenarios as us.
The title is the first thing potential answerers will see, and if your title isn't interesting, they won't read the rest. So make it count:
- Pretend you're talking to a busy colleague and have to sum up your entire question in one sentence: what details can you include that will help someone identify and solve your problem? Include any error messages, key APIs, or unusual circumstances that make your question different from similar questions already on the site.
- Spelling, grammar and punctuation are important! Remember, this is the first part of your question others will see - you want to make a good impression. If you're not comfortable writing in English, ask a friend to proof-read it for you.
- If you're having trouble summarizing the problem, write the title last - sometimes writing the rest of the question first can make it easier to describe the problem.
Whether it's a question in a channel or a question in a DM, it's better to write a simple title or a short description than to just write "Can I ask you a question".
Examples:
- Bad: hi, can I ask you?
- Good: can you let me know where to generate step function..I remembered you said we better use the generator when we want to develop step function.. it's in the AWS management console?
- Bad: C# Math Confusion
- Good: Why does using float instead of int give me different results when all of my inputs are integers?
- Bad: [php] session doubt
- Good: How can I redirect users to different pages based on session data in PHP?
- Bad: android if else problems
- Good: Why does str == "value" evaluate to false when str is set to "value"?
In the body of your question, start by expanding on the summary you put in the title. Explain how you encountered the problem you're trying to solve, and any difficulties that have prevented you from solving it yourself. The first paragraph in your question is the second thing most readers will see, so make it as engaging and informative as possible.
Not all questions benefit from including code, but if your problem is with code you've written, you should include some. But don't just copy in your entire program! Here are some guidelines:
- Include just enough code to allow others to reproduce the problem. For help with this, read How to create a Minimal, Complete, and Verifiable example.
- If it is possible to create a live example of the problem that you can link to (for example, on http://sqlfiddle.com/ or http://jsbin.com/) then do so - but also copy the code into the question itself.
- DO NOT post images of code, data, error messages, etc. - copy or type the text into the question. Please reserve the use of images for diagrams or demonstrating rendering bugs, things that are impossible to describe accurately via text.
Reproducing is very very very important. Check the following link to know how to create a Minimal Reproducible Example. This will help to debug a lot:
How to create a Minimal, Reproducible Example - Help Center
Some useful links: