When writing code, it usually takes a lot of time to find out the cause of bugs. How to locate bugs quickly determines your development efficiency to a large extent. Here are some of my experiences.

Improve coding quality

When a project is simple enough, the importance of coding specifications and code quality is often not realized. When a project is large enough to require multiple people to collaborate or receive code from others, you realize how important it is to have uniform coding specifications, design of the project structure, legibility of the code, and annotations of the specifications.

Improving the quality of your code not only helps you find bugs faster, but also reduces the number of bugs. Bad code is like a pile of junk, while good code is like a sorting box, and when you’re looking for something, it’s easy to see which one is more efficient.

Of course, improving the quality of coding is not an overnight feat. It requires a solid foundation of knowledge, good coding practices, and accumulated experience in making mistakes. You can then write an article on how to write high-quality code.

Read the error message

If the browser has an error message, we can use the error message to determine the type of error and the probable cause of the error.

Such as:

  1. At runtime, the code attempts to access an objectattrProperty, and the object is not defined. In this case, we only need to search for keywords in the error pageattrAnd the outputattrYou know what the error is, right
Uncaught TypeError: Cannot read property 'attr' of undefined
Copy the code
  1. Map is an array method, and as expected, A is not an array, so the result is that A is not in the format we expect
Uncaught TypeError: a.map is not a function
Copy the code
  1. Js code format error: ESLint will output an error to check whether quotes, commas, braces, and braces are complete
Uncaught SyntaxError: Invalid or unexpected token
Copy the code
  1. Sometimes, even when you understand the error message, you don’t know what’s wrong with your code. You can copy the error message and search stackOverflow, SegmentFault, and other professional q&A sites. If you can’t find a reasonable answer, search Google or Baidu. Trust that there are people out there who have had similar problems.

Use the console

Sometimes, when your code doesn’t work the way you want it to, but doesn’t output any valid error messages, you can use the console method to print out the necessary information.

How to use it?

For example, when we click the submit button, we don’t initiate a submit request. At this point, we need to look at the source code to find out what steps have been taken from clicking the submit button to making the request. Output key information at key steps, such as if else criteria, arrays and objects being traversed, and return statements that may interrupt execution.

Matters needing attention

When using console output, you are advised to use keywords and do not use meaningless numbers and letters.

// good
console.log('attrValue'.this.attrValue)
console.log('getModule method criteria ', isShow)

// bad
console.log(Awesome!.this.attrValue)
console.log(isShow)
Copy the code

In addition, it is recommended to delete console debugging code that is no longer used after troubleshooting to avoid unnecessary interference when searching for other errors.

exclusions

I didn’t change it. I just added some code somewhere else and it didn’t work.

How to do? If there are five methods abcd on the page, and we comment out a, B, C, and D each time we comment out the code, then we run the code once. If the code works properly after we comment out D, then the problem is D.

Stripping method

If a page has a lot of code, exclusion may be inefficient, so try stripping.

The same method (component) that works fine on page A doesn’t work on page B. At this time, you can build a new page, which only put this component, and then run, if there is no exception, first can be ruled out, not this component problem. Next, add the conditions that the B page might affect the method (component) one by one to see which condition is causing the exception.

On-line troubleshooting

Sometimes the online code fails and cannot be reproduced locally, because the online code does not use console and the online code is compressed and confused, making it difficult to debug.

In this case, try sourceMap, which is enabled in the WebPack configuration file and generates the corresponding.map file at packaging time. Then upload the packaged file to the server as a whole, so that when you debug code on the line, you have a copy of the original code, in addition to the compressed obfuscated code, which is easy to break and read.

There are a few downsides to doing this, though: it takes longer to package, and it exposes native code. Therefore, it is recommended that sourceMap be turned off and used only for fixing online bugs that cannot be reproduced locally. Also, after the fix is complete, make a new package without sourceMap and upload it to the server to avoid local code leakage.

More information about sourceMap can be found at the following links:

JavaScript Source Map details

Break the casserole: Sourcemap in Webpack