코드를 디버깅하기 위해 디버거를 사용하는 이유는 무엇입니까? 이렇게 하면 다양한 소스 코드를 읽을 수 있습니다!

디버깅을 위해 디버거를 사용해야 하는 이유를 모르는 학생들이 많습니다. console.log가 작동하지 않나요? 그리고 디버거 사용법을 알았음에도 아직 이해하지 못하는 코드가 많습니다. 복잡한 소스 코드를 어떻게 디버깅하나요? 이 기사에서는 이러한 디버깅 도구를 사용해야 하는 이유에 대해 설명합니다. 모든 사람에게 도움이 되기를 바랍니다.

console.log vs Debugger

대부분의 학생들이 디버깅을 위해 console.log를 사용하고 콘솔에서 보고 싶은 변수 값을 인쇄한다고 생각합니다. [추천 관련 튜토리얼: nodejs 비디오 튜토리얼, 프로그래밍 교육]

이것은 요구 사항을 충족할 수 있지만 객체 인쇄에 있어서는 작동하지 않습니다.

예를 들어 webpack 소스 코드에서 컴파일 개체의 값을 보려면 다음과 같이 인쇄합니다.

하지만 개체의 값도 개체인 경우에는 그렇지 않습니다. 확장되지만 [Object] [Array]가 인쇄됩니다.

더 치명적인 것은 너무 오래 인쇄하면 버퍼 크기를 초과하고 터미널의 표시가 불완전해진다는 것입니다.

그리고 디버거를 사용하여 실행하는 경우 여기에 중단점을 설정하여 이러한 내용이 표시되는지 확인하세요. 문제는 사라질 것입니다:

일부 학생들은 간단한 값을 인쇄할 때 console.log를 사용하는 것이 매우 편리하다고 말할 수 있습니다.

예:

정말요?

그런 다음 logpoint를 사용하는 것이 좋습니다.

여기에서 코드가 실행되면 다음이 인쇄됩니다.

디버깅 후 console.log를 사용하면 오염 코드가 없습니다. , 이 콘솔을 삭제해야 하는 것 아닌가요?

하지만 로그포인트는 사용되지 않으며 단지 중단점 설정일 뿐이며 코드에는 없습니다.

물론, 가장 중요한 것은 Debugger로 디버깅할 때 호출 스택과 범위를 볼 수 있다는 것입니다!

첫 번째는 코드의 실행 경로인 호출 스택입니다.

예를 들어 이 앱의 함수 구성 요소의 경우 이 함수 구성 요소 렌더링이 workLoop, BeginWork 및 renderWithHooks 프로세스를 거치는 것을 볼 수 있습니다.

호출 스택의 각 프레임을 클릭하면 어떤 로직이 실행되는지 확인하세요. 예를 들어, 이 함수 구성 요소의 파이버 노드를 볼 수 있습니다.

다음으로 범위가 있습니다. 각 스택 프레임을 클릭하면 각 함수의 범위에 있는 변수를 볼 수 있습니다. with Debugger 코드의 실행 경로와 각 단계의 범위 정보입니다. 그리고 console.log를 사용하시나요?

변수 값만 볼 수 있습니다.

얻는 정보량의 차이는 사소한 차이가 아닙니다. 디버깅 시간이 길어질수록 다른 사람들은 코드의 실행 프로세스에 대해 점점 더 명확해질 것입니다. 하지만 console.log를 사용하는 것은 어떻습니까? 코드 실행 경로를 볼 수 없기 때문에 여전히 이전과 동일합니다.

그래서 라이브러리의 소스 코드를 디버깅하든, 비즈니스 코드를 디버깅하든, Node.js를 디버깅하든 웹 페이지를 디버깅하든, 인쇄하려는 경우에도 디버거 중단점을 사용하는 것이 좋습니다. 로그가 있는 경우 LogPoint를 사용할 수도 있습니다.

그리고 문제를 해결할 때 디버거를 사용할 때 예외 중단점을 추가할 수 있으며 예외가 발생하는 지점에 도달하면 코드가 중지됩니다.

정렬할 호출 스택을 볼 수 있습니다. 오류 이전의 모든 코드가 무엇이든 범위를 통해 각 변수의 값을 볼 수 있습니다.

이렇게 하면 오류 해결이 쉽겠죠?

그리고 console.log를 사용하시나요?

아무것도 아닙니다. 추측만 할 수 있습니다.

성능

앞서 언급한 것처럼 디버거 디버깅은 코드의 실행 경로를 볼 수 있지만 코드의 실행 경로가 구불구불한 경우가 많습니다.

예를 들어 React는 각 Fiber 노드를 처리하고 각 노드는 BeginWork를 호출합니다. 처리 후 다음 노드가 처리되고 BeginWork가 다시 호출됩니다.

작은 길을 택한 다음 주요 도로로 돌아가서 다른 작은 길을 택한 것처럼 디버거를 사용하면 현재 작은 길의 실행 경로만 볼 수 있고 다른 작은 길의 경로는 볼 수 없습니다.

이때 성능 도구를 사용하여 코드 실행의 전체 그림을 확인한 다음 디버거를 사용하여 각 코드 실행 경로의 세부 정보를 살펴볼 수 있습니다.

SourceMap

sourcemap은 매우 중요합니다. 왜냐하면 우리가 실행한 것은 기본적으로 읽을 수 없는 컴파일되고 패키징된 코드이기 때문입니다. 이런 종류의 코드를 디버깅하는 것은 의미가 없으며, sourcemap을 사용하면 직접 디버깅할 수 있습니다. 원본 소스 코드.

예를 들어, vue는 소스맵과 연결한 후 ts 소스 코드를 직접 디버깅할 수 있습니다.

nest.js도 다음과 같습니다.

소스맵을 사용하지 않는 경우 다음을 수행하세요. 소스 코드를 이해하지만 디버깅하는 것은 컴파일입니다. 이후 코드를 어떻게 읽을 수 있나요?

줄 읽기

앞서 언급한 Debugger, Performance, SourceMap은 코드 디버깅을 위한 도구일 뿐입니다. 디버깅 도구를 알고 있지만 여전히 코드를 읽을 수 없으면 어떻게 해야 하나요?

이건 불가능하다고 생각해요.

왜 그런 말을 하는 걸까요?

반응 소스 코드를 예로 들어보겠습니다.

스위치 케이스 이해가 되시나요? 삼항 연산자를 이해할 수 있나요? 함수 호출을 이해할 수 있나요?

모든 코드 줄은 읽을 수 있는데, 모든 코드가 이 코드 줄로 구성되어 있지 않나요?

또한 단계별로 코드 실행 경로를 알 수 있습니다.

왜 코드의 각 줄을 이해할 수 있지만 모두 읽을 수는 없나요?

코드가 너무 많고 시간이 부족하기 때문일 것입니다.

먼저 한 줄, 한 함수, 작은 함수의 구현 과정을 이해해야 하고, 차츰차츰 쌓아가면서 이해할수록 더 많은 코드를 이해할 수 있게 됩니다.

요약

이 글에서는 디버깅 도구를 사용해야 하는 이유와 복잡한 코드를 이해하는 방법에 대해 설명합니다.

console.log에는 단점이 너무 많습니다. 큰 개체는 완전히 인쇄할 수 없으며, 터미널 버퍼가 초과되고, 개체 속성을 확장할 수 없는 등 모든 사람이 사용하는 것은 권장되지 않습니다. 인쇄하고 싶은 경우에도 LogPoint를 사용할 수 있습니다.

디버거를 사용하면 코드의 실행경로인 콜스택과 각 스택 프레임의 범위를 볼 수 있고, 처음부터 현재까지 코드가 어떤 경험을 했는지 알 수 있지만, console.log는 특정 변수의 값을 알고 있습니다.

또한 오류가 보고되면 예외 중단점을 사용하여 코드 실행 경로를 정렬하여 오류 원인을 해결할 수도 있습니다.

하지만 디버거는 하나의 실행 경로만 볼 수 있습니다. 성능을 사용하여 코드 실행의 전체 프로세스를 기록한 다음 디버거를 사용하여 경로 중 하나의 실행 세부 정보를 살펴볼 수 있습니다.

게다가 원본 소스 코드만 디버깅하는 것이 합리적입니다. 그렇지 않으면 컴파일된 코드를 디버깅하면 정보가 훨씬 적어집니다. SourceMap을 사용하면 Vue, React의 소스 코드든 Nest.js, Babel 등의 소스 코드든 소스 코드에 연결할 수 있습니다.

디버깅 방법을 배운 후에는 다양한 코드를 디버깅할 수 있습니다. 코드의 모든 줄이 기본 구문이므로 이해하지 못하면 이해할 수 있기 때문입니다. 코드가 너무 복잡하기 때문입니다. 코드를 한 줄씩 읽고, 함수별로 읽고, 각 함수의 구현을 정렬하고, 천천히 축적하려면 더 많은 인내심이 필요합니다.

디버거, 퍼포먼스, 소스맵 등을 기반으로 한 디버깅 코드를 마스터한 후에는 다양한 웹페이지와 Node.js 코드를 디버깅하고 다양한 소스코드를 읽어볼 수 있습니다! [추천 학습: javascript 동영상 튜토리얼]

위 내용은 코드를 디버깅하기 위해 디버거를 사용하는 이유는 무엇입니까? 이렇게 하면 다양한 소스 코드를 읽을 수 있습니다!의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!