This is the 12th day of my participation in Gwen Challenge

The words written in the front

Debug is very important during the development phase, and the proper use of breakpoints can help us locate problems quickly. But it is a pity that there is almost no such article to sum up, maybe it is too simple? So at that time, I was not sure whether the posture of my debug was correct. So LET me share how I Debug. (God can be skipped directly)

In order to cover a wider range, we are talking about debugging the entire process from page request to back end.

Prerequisite: Start code in Debug mode (in general, run mode is useless during development)

Find the request entry

First to know what the REQUESTED URL is, F12 opens the developer debugger. We take the zhuanlan.zhihu.com/p/272065407 this site as an example. We are only concerned with requests for data, so we only need to select the XHR (XMLHttpRequest) option.

Right, now the average query on a page will consist of multiple URL requests, some for body content, some for photos, and some for comments. By the way, these are all made into separate microservices.

We can probably guess by looking at the name of the URLwww.zhihu.com/api/v4/arti…This request is for comments. We can determine exactly what the request is by clicking on response in the lower right and seeing the data content returned by the server.Of course, you can copy the URL directly into the browser address bar and query the result directly.

Proxy forwarding to local

If it is a project with no separation of the front and back ends, i.e. the general front and back end code in a code project, you can look directly at the next step.

For projects where the front and back ends are completely separated, we back-end staff generally do not have front-end code, so we cannot start front-end code locally and send front-end requests locally. In this case, there are two ways to send the request, one is to use Postman to send the request to the local, but usually need to set some cookies or headers for the request, which is slightly troublesome. Another way is to turn on the proxy.

First explain the agent’s literal meaning, for chestnut, we want to buy a car, can be done all by themselves, find their own options, their transfer formalities, workshop procedures, but also can find a agency to help us deal with, so we have to do is to look for an intermediary company, please, and then entrust them to help us (agent) buy a car.

The role of the proxy here is to intercept the request for the page and then “forward” the proxy to the locally launched code according to preset rules.

For Charles, we’ll set it in Tools –> Map Remote

From is the HTTP/HTTPS request we want to intercept, and to is the IP that the proxy will forward to the local. The following figure is roughly the same as the urlwww.zhihu/api/v3/arti…

Find the back-end code entry

With the request URL, we need to start looking for the back-end entry. Any project in general will have address translation mapping, such as the www.zhihu.com/creator/ana…

Once you know the rules for mapping front-end urls to the back end, it’s much easier to find the back end code entry. Assuming that www.zhihu.com/creator/ana…

For well-organized projects, the folder name and package name can be identified faster. If in doubt, we can put a breakpoint on the first line of the code, and the page sends a request to see if the code breaks at the breakpoint.

Of course, there are cases where urls are not mapped, and you can directly search the URL keyword globally to find the back-end code entry. Bold speculation that example www.zhihu.com/api/v4/arti…

Several buttons for breakpoints

This section is the most basic interruption point description. I used Goland for the demo (actually the same as Eclipse).

  • Execute the next method: think of it as a line by line, such as func1() above, and then stop at func2().
  • Entry method: When we click on the entry method at func1(), it will stop at line 28 (regardless of the breakpoint above).
  • Exit method: When you get to line 28, click exit method to return to line 8. That is, exit the method.
  • Execute to the next breakpoint: as shown in the figure above, execute to the next breakpoint and stop at line 28.
  • Mask all breakpoints: Breakpoints are invalid and run mode is executed.

Observe changes in variable values

Learn to observe the values of variables and get clues. There are generally two places to view variable information as shown below (Eclipse does not support viewing it on every line of code). However, for some code with a lot of loops and conditional judgments, we can directly print the variables to view, and the printed information can be switched to view in the lower left corner of the console.

Breakpoint location

Use as many points of interruption as possible to pinpoint the code location of the problem. For unfamiliar code, it is unlikely to be able to type the code in the wrong code once, and often miss the code again and again. The problem code is usually found in a combination of the next step and the entry method.

At the same time, in cases where the code uses decorator patterns, or where there are multiple implementations of an interface, and you are not familiar with the code, you may not know which implementation the object is going into, so you can put breakpoints on each implementation entry.

In another case, there are multiple business validation rules in some places, and sometimes it is necessary to know the order of execution of these business rules. Breakpoints are required for each business rule code to obtain their execution order.

Multithreaded Debug

Multithreaded debugging sometimes requires manual thread switching to observe the condition of a particular thread (for Java’s sake, Go’s coroutines are called threads). For example, if you look at the arrow below, it is currently in the main Thread.

And there’s actually a thread running behind it, so we can switch Goroutine18 by clicking on the arrow, and then execute next, and the thread will continue to execute.

It is worth mentioning that when we debug multithreaded programs, we sometimes find that the expected thread does not execute, because our main thread (usually the main thread) has finished executing, so we directly exit the program. At this point we should add sleep logic after the main thread, or loop logic to ensure that the main thread does not exit immediately.

The last

The Debug process is basically like this. In general, it is to find the URL first, then find the back-end code entry, and break many points to gradually lock the problem code.