IDE에서 디버깅이 더 나은 이유는 무엇입니까? [닫은]

저는 20 년 이상 C, Perl, SQL, Java, PHP, JavaScript 및 최근 Python으로 프로그래밍 한 소프트웨어 개발자였습니다. 신중하게 생각하고 잘 배치 된 디버깅 print문을 사용하여 디버깅 할 수없는 문제가 없었습니다 .

많은 사람들이 내 기술이 원시적이라고 말하고 IDE에서 실제 디버거를 사용하는 것이 훨씬 좋습니다. 그러나 내 관찰에 따르면 IDE 사용자는 돌 나이프와 베어 스킨을 사용하여 내가 할 수있는 것보다 더 빠르거나 더 성공적으로 디버깅하지 않는 것으로 보입니다. 올바른 도구를 배우는 데 진심으로 열려 있지만 시각적 디버거를 사용하는 데있어 매력적인 이점을 보여주지 못했습니다.

또한 중단 점을 설정하고 변수의 내용을 표시하는 방법의 기초를 넘어 IDE를 사용하여 효과적으로 디버깅하는 방법을 보여주는 자습서 나 책을 읽지 않았습니다.

내가 무엇을 놓치고 있습니까? 진단 디버깅을 신중하게 사용하는 것보다 IDE 디버깅 도구가 훨씬 더 효과적인 이유는 무엇입니까 print?

IDE 디버깅의 더 훌륭한 기술을 보여주는 자료 (자습서, 서적, 스크린 캐스트)를 제안 할 수 있습니까?

달콤한 답변! 시간을 내 주셔서 감사합니다. 매우 밝습니다. 나는 많은 투표를했고 아무도 투표하지 않았다.

몇 가지 주목할만한 점 :

• 디버거를 사용하면 변수, 코드 또는 런타임 환경의 다른 측면을 임시로 검사하거나 변경하는 데 도움이 될 수 있지만 수동 디버깅을 위해서는 응용 프로그램을 중지, 편집 및 다시 실행해야합니다 (재 컴파일 필요).
• 디버거는 실행중인 프로세스에 연결하거나 크래시 덤프를 사용할 수 있지만 수동 디버깅에서는 결함을 "복제하는 단계"가 필요합니다.
• 디버거는 복잡한 데이터 구조, 다중 스레드 환경 또는 전체 런타임 스택을 쉽고 읽기 쉬운 방식으로 표시 할 수 있습니다.
• 디버거는 거의 모든 디버깅 작업을 수행하기 위해 시간과 반복 작업을 줄일 수있는 여러 가지 방법을 제공합니다.
• 비주얼 디버거와 콘솔 디버거는 모두 유용하며 많은 기능이 공통적입니다.
• 또한 IDE에 통합 된 시각적 디버거를 사용하면 단일 통합 개발 환경 (따라서 이름)에서 스마트 편집 및 IDE의 다른 모든 기능에 편리하게 액세스 할 수 있습니다.

IDE 디버거가 코드에서 추적 메시지를 제공 할 수있는 일부 기능의 예 :

• 보기 호출 스택을 당신에게 당신의 현재 스택 프레임에 대한 컨텍스트를 제공, 어느 시점에서.
• 추적을 추가하기 위해 다시 컴파일 할 수없는 라이브러리로 들어가 십시오 (디버그 기호에 액세스 할 수 있다고 가정).
• 프로그램이 실행되는 동안 변수 값 변경
• 편집 및 계속- 코드 실행 중에 코드 를 변경 하고 변경 결과를 즉시 확인할 수있는 기능
• 변수가 바뀌는시기 를 보고 변수 를 볼 수 있어야합니다
• 코드 의 기능을 확인하려면 코드 섹션 을 건너 뛰거나 반복 할 수 있습니다. 이를 통해 이론적 변경을 테스트하기 전에 테스트 할 수 있습니다.
• 메모리 내용 을 실시간으로 검사
• 응용 프로그램에서 예외 를 처리하더라도 특정 예외 가 발생 하면 경고합니다 .
• 조건부 중단 점 ; 스택과 변수를 분석 할 수 있도록 예외적 인 상황에서만 응용 프로그램을 중지합니다.
• 뷰 스레드 컨텍스트 (다른 스레드로부터 트레이스가 출력 인터리브되는 바와 같이) 추적을 달성하기 어려울 수있는 멀티 스레드 애플리케이션에서를.

요약하면, print 문은 (일반적으로) 정적 이며 원래 명령문이 충분하지 않은 경우 추가 정보를 얻으려면 다시 컴파일해야합니다. IDE는 이러한 정적 장벽을 제거 하여 손끝에서 다이나믹 한 툴킷을 제공합니다.

처음 코딩을 시작했을 때 디버거와 관련하여 큰 문제가 무엇인지 이해할 수 없었으며 추적 (UNIX에 있었고 디버거는 GDB)으로 무엇이든 얻을 수 있다고 생각했습니다. 그러나 그래픽 디버거를 올바르게 사용하는 방법을 배우면 인쇄 문으로 돌아가고 싶지 않습니다.

• IDE 디버거를 사용하면 런타임에 변수 값을 변경할 수 있습니다.

• IDE 디버거를 사용하면 실행이 시작될 때보고 싶지 않은 변수의 값을 볼 수 있습니다.

• IDE 디버거를 사용하면 호출 스택을보고 이상한 값을 전달한 함수의 상태를 검사 할 수 있습니다. (이 기능은 수백 곳에서 호출된다고 생각하십시오.이 이상한 값이 어디에서 오는지 모릅니다)

• IDE 디버거를 사용하면 줄 번호가 아닌 조건에 따라 코드의 어느 시점에서나 조건부로 실행을 중단 할 수 있습니다.

• IDE 디버거를 사용하면 처리하지 않고 예외 처리되지 않은 경우 프로그램 상태를 확인할 수 있습니다.

고객이 메모리 덤프를 가져 와서 "프로그램이 다운되면 왜 그런지 말해 줄 수 있습니까?"

• 코드 전체를 통한 인쇄 문은 가독성을 떨어 뜨립니다.
• 디버그 목적으로 만 추가 및 제거하는 데 시간이 많이 걸립니다
• 디버거는 호출 스택을 추적하여 현재 위치를 쉽게 확인할 수 있습니다.
• 변수는 즉시 수정 될 수 있습니다
• 진단을 돕기 위해 실행 일시 정지 중에 임시 명령을 실행할 수 있습니다.
• print 문과 함께 INCONJUNCTION과 함께 사용할 수 있습니다. Debug.Write ( "...")

print 문을 사용하여 디버깅하는 것은 잃어버린 예술이며 모든 개발자가 배우는 것이 매우 중요합니다. 그렇게하는 방법을 알고 나면 IDE를 통하는 것보다 특정 방식으로 버그를 디버깅하는 것이 훨씬 쉬워집니다. 이 기술을 알고있는 프로그래머도 논박 할 목적으로 로그 메시지 (실제로 로그를 읽지 않을 것입니다)에 넣을 유용한 정보가 무엇인지 잘 알고 있습니다.

즉, 다른 종류의 버그에 대해서는 훨씬 더 쉽기 때문에 단계별 디버거를 사용하는 방법을 알아야합니다. 나는 이유를 설명하기 위해 이미 게시 된 다른 훌륭한 답변에 맡길 것입니다 :)

내 머리 꼭대기에서 :

1. 복잡한 객체 디버깅 -디버거를 사용하면 객체의 내부를 깊이 파고들 수 있습니다. 객체에 복잡한 객체 배열이있는 경우 print 문은 지금까지만 얻을 수 있습니다.
2. 과거 코드를 단계별로 실행하는 기능 -디버거를 사용하면 실행하지 않으려는 과거 코드를 건너 뛸 수 있습니다. 사실, 수동으로도 할 수 있지만 주입해야 할 코드가 훨씬 많습니다.

IDE에서 디버그하는 대안으로 다음을 수행 할 수 있는 PHP 라이브러리 를 사용하여 훌륭한 Google Chrome 확장 프로그램 PHP 콘솔 을 사용해 볼 수 있습니다 .

• Chrome 자바 스크립트 콘솔 및 알림 팝업에서 오류 및 예외를 확인하세요.
• 모든 유형 변수를 덤프하십시오.
• 원격으로 PHP 코드를 실행하십시오.
• 비밀번호로 액세스를 보호하십시오.
• 요청별로 콘솔 로그를 그룹화하십시오.
• 텍스트 편집기에서 error file : line으로 이동하십시오.
• 오류 / 디버그 데이터를 클립 보드에 복사합니다 (테스터 용).

나는 거의 20 년 동안 개발하지 않았지만 IDE / 디버거를 사용하면 다음과 같은 일을 할 수 있습니다.

• 내가 인쇄 진술에 포함하지 않은 것으로 생각 될 수있는 모든 것들을보십시오
• 내가 생각했던 경로와 일치하는지 확인하기 위해 코드를 단계별로 실행하십시오.
• 코드가 특정 분기를 사용하도록 변수를 특정 값으로 설정

IDE를 사용하는 한 가지 이유는 최신 IDE가 단순한 중단 점 이상을 지원하기 때문일 수 있습니다. 예를 들어 Visual Studio는 다음과 같은 고급 디버깅 기능을 제공합니다.

• 조건부 중단 점 정의 (조건이 충족되는 경우에만 또는 중단 점에서 명령문이 실행될 때 n 번째에만 중단)
• 처리되지 않은 예외 또는 (특정) ecxeption이 발생할 때마다 중단
• 디버깅 중 변수 변경
• 실행될 다음 줄을 설정하여 코드를 반복
• 기타

또한 디버거를 사용할 때 디버깅이 끝나면 모든 print 문을 제거하지 않아도됩니다.

내가 다른 답변에서 보지 못했던 것에 놀랍게도 한 가지 디버깅 방법은 상호 배타적이지 않다는 것입니다 .

printf표준 디버거 (IDE 기반이든 아니든)를 사용하더라도 디버깅은 아주 훌륭하게 작동 할 수 있습니다. 특히 로깅 프레임 워크를 사용하면 출시 된 제품의 전부 또는 대부분을 고객 문제 진단에 사용할 수 있습니다.

여기에있는 다른 모든 답변에서 언급했듯이 표준 디버거의 중요한 장점은 프로그램 상태의 세부 사항을보다 쉽게 ​​검사하고 잠재적으로 변경할 수 있다는 것입니다. 무엇을보고 싶을 지 미리 알 필요가 없습니다. 모두 손끝에서 사용할 수 있습니다.

내 경험상 간단한 인쇄물에는 아무도 언급하지 않은 큰 이점이 있습니다.

IDE 디버거의 문제점은 모든 것이 실시간으로 발생한다는 것입니다. 특정 시간에 프로그램을 중단 한 다음 한 번에 하나씩 단계를 수행하면 이전에 발생한 상황을 갑자기보고 싶다면 되돌아 갈 수 없습니다. 이것은 우리의 뇌가 작동하는 방식과 상충됩니다. 뇌는 정보를 수집하고 점차 의견을 형성합니다. 그렇게 할 때 이벤트를 여러 번 반복해야 할 수도 있지만 특정 지점을 지나면 되돌아 갈 수 없습니다.

이와 달리 선택된 일련의 인쇄물 / 로깅은 "일시적 이벤트의 공간 투영"을 제공합니다. 그것은 당신에게 일어난 일에 대한 완전한 이야기를 제공하며, 위아래로 스크롤하여 몇 번이고 매우 쉽게 돌아가고 갈 수 있습니다. "B가 발생하기 전에 A가 발생 했음"과 같은 질문에 쉽게 대답 할 수 있습니다. 원하는 패턴을 볼 수도 있습니다.

내 경험으로는. IDE와 디버거는 하나의 단일 호출 스택에 문제가있을 때 간단한 문제를 해결하고 특정 충돌시 시스템의 현재 상태를 탐색하는 환상적인 도구입니다.

그러나 점진적인 국가 변화가 수반되는 더 어려운 문제에 접근 할 때. 예를 들어, 하나의 알고리즘이 데이터 구조를 손상시킨 경우, 그로 인해 아노 터 알고리즘이 실패했습니다. 또는 "얼마나 자주 이런 일이 일어나는가?"와 같은 질문에 대답하고 싶다면, "일이 일어날 것으로 예상되는 방식으로 일이 일어나는가?" 그런 다음 "이전 fashined"로깅 / 인쇄 기술은 분명한 이점이 있습니다.

가장 좋은 방법은 가장 적합한 기술 중 하나를 사용하는 것입니다. 예를 들어, 로깅 / 프린트를 사용하여 버그를 발견하고 현재 상태를보다 자세히 탐색해야하는 중단 점에서 일시 중지합니다.

하이브리드 접근법도 있습니다. 예를 들어 console.log (object)를 수행하면 로그에 데이터 구조 위젯이 생겨 더욱 상세하게 확장하고 탐색 할 수 있습니다. 이는 "죽은"텍스트 로그보다 많은 이점이 있습니다.

print 문으로 멀티 스레드 응용 프로그램을 디버깅하면 바나나가 생길 수 있습니다. 예, 여전히 print 문으로 할 수 있지만 많은 문이 필요하며 멀티 스레드 실행을 에뮬레이트하기 위해 명령문에서 순차적 인 인쇄를 풀려면 오랜 시간이 걸립니다.

인간의 두뇌는 불행하게도 단일 스레드입니다.

책에 대한 포인터를 요청한 이후로 ... Windows 디버깅이 진행되는 한 John Robbins는 Windows 디버깅에 대한 몇 가지 좋은 책을 보유하고 있습니다.

Microsoft .NET 및 Microsoft Windows 용 응용 프로그램 디버깅

최신 버전 ( Microsoft .NET 2.0 응용 프로그램 디버깅 )은 .NET 전용이므로 기본 코드 디버깅 (.NET 및 기본 모두 포함)을 원할 경우 이전 링크 (예 : 첫 번째 링크)가 필요할 수 있습니다.

개인적으로 대답은 "통합 디버거 / IDE는 명령을 펀칭 할 필요없이 다양한 정보를 신속하게 제공합니다. 정보는 무엇을 말하지 않아도 앞에있을 수 있습니다. 보여줘

정보를 쉽게 검색 할 수있는 것은 명령 줄 디버깅 또는 "printf"디버깅보다 더 나은 정보입니다.

printf에 비해 디버거의 장점 ( IDE 디버거가 아니라 디버거에 주목 )

1. 감시 점을 설정할 수 있습니다. 이것은 메모리 손상을 찾는 가장 좋아하는 방법 중 하나입니다.

2. 현재 재 컴파일 할 수없는 바이너리를 디버깅 할 수 있습니다

3. 재 컴파일하는 데 시간이 오래 걸리는 바이너리를 디버깅 할 수 있음

4. 변수를 즉석에서 변경할 수 있습니다

5. 즉시 기능을 호출 할 수 있습니다

6. 디버그 상태 정보가 플러시되지 않아 타이밍 문제를 정확하게 디버깅 할 수없는 문제가 없습니다.

7. 디버거는 코어 덤프에 도움이되고, 인쇄 문은 그렇지 않습니다

이것이 VS.NET 디버깅 창에서 가장 많이 사용하는 것입니다.

• 다른 사람의 코드를 알아낼 수있는 좋은 방법 인 콜 스택
• 현지인 및 시계.
• 기본 창은 기본적으로 C # 콘솔이며 변수 내용을 변경하고 물건을 초기화하는 등의 작업을 수행 할 수 있습니다.
• 줄을 건너 뛰는 기능은 다음 명령문이 다른 곳에서 실행되도록 설정합니다.
• 변수 위로 마우스를 가져 가서 값을 보여주는 툴팁이 있습니다.

요약하면 작은 창뿐만 아니라 실행 코드의 상태를 360도 볼 수 있습니다.

이런 종류의 물건을 가르치는 책을 찾지 못했지만 다시는 매우 단순 해 보입니다. 거의 WYSIWYG입니다.

• 디버거는 실행중인 프로세스에 연결할 수 있습니다

• 디버거에서 스레드 코드를 디버깅하기가 더 쉽습니다.

IDE 디버거를 사용하면 실행을 중단 할 때마다 현재 범위의 모든 변수 값 (콜 스택까지)을 볼 수 있습니다.

인쇄 문은 큰하지만 생산할 수있는 특정 장소에서 화면에 너무 많은 정보를 덤프 할 수 있습니다 전체 인쇄 문을 많이.

또한 많은 IDE 디버거를 사용하면 메소드를 입력하고 평가할 수 있으며 정지 된 상태에서 멤버를 평가할 수 있으므로 인쇄 문의 양이 더 늘어납니다.

그러나 일부 언어에서는 디버거가 다른 언어보다 낫다고 생각합니다 ...

필자의 일반적인 의견은 IDE 디버거는 Java 또는 C #와 같은 관리되는 언어에서 절대적으로 놀랍도록 훌륭하고 C ++에서는 상당히 유용하며 Python과 같은 언어를 스크립팅하는 데는 유용하지 않다는 것입니다. 모든 스크립팅 언어에 대한 디버거).

Java 개발을 할 때 IntelliJ IDEA의 디버거를 좋아합니다. Python을 사용할 때 print 문만 사용합니다.

누군가 위에서 말했듯이 : Debugger! = IDE.

gdb와 (당시) TurboDebugger (독립형)는 그들이 지원하는 언어에 대해 잘 작동합니다. 감사합니다. (또는 더 오래된 기술 : xBase 실행 파일 자체에 연결된 Clipper 디버거)-이 중 어느 것도 IDE가 필요하지 않습니다.

또한 C / ++ 코딩은 더 드물지만 printf 문은 때로는 찾으려고하는 버그를 가려줍니다! (예를 들어 스택의 자동 변수에서 초기화 문제 또는 메모리 할당 / 정렬)

마지막으로 다른 사람들이 언급했듯이 두 가지를 모두 사용할 수 있습니다. 일부 실시간 문제는 거의 인쇄가 필요하거나 최소한 "* video_dbg = (is_good? '+': '-');" 비디오 메모리 어딘가에. 내 나이가 보이고 있습니다, 이것은 DOS에있었습니다 :-)

TMTOWTDI

다른 포스터가 말한 것 외에도 컴퓨터와 함께 한 번에 한 줄씩 단계별로 실행하는 것이 좋습니다. 한 번에 한 줄씩 생각해야하기 때문입니다. 종종 '다음 라인'버튼을 클릭하면 변수 값을 보지 않아도 버그를 잡을 수 있습니다. 그러나 Bill은 아마도이 기술을 이미 가지고 있기 때문에 내 대답이 도움이 될 것이라고 생각하지 않습니다.

학습 자료에 관한 한, 나는 전혀 사용하지 않았습니다. 나는 모든 메뉴와 옵션을 탐색합니다.

이것은 실제 프로그래머의 실제 질문입니까?

print 문을 사용하여 디버깅하고 IDE를 사용하여 디버깅하는 데 5 분을 소비 한 사람은 묻지 않고 바로 사용할 수 있습니다!

디버깅을 위해 인쇄와 IDE를 모두 사용했으며 IDE를 사용하여 디버깅하는 것이 좋습니다. 작동하지 않는 유일한 시간은 온라인 게임 디버깅과 같이 시간이 중요한 상황에서 인쇄 문으로 코드를 흩어 버리고 끔찍하게 잘못 된 로그 파일을 보는 것입니다. 그래도 여전히 알아낼 수 없으면 인쇄물을 더 추가하고 반복하십시오.

IDE에서 콘솔 디버거 vs printf 및 vs 디버거의 유용한 기능을 언급하고 싶었습니다.

원격 응용 프로그램 (확실히 DEBUG 모드로 컴파일 됨)에 연결하고 POSIX tee유틸리티를 사용하여 디버거 출력을 파일에 덤프하는 상태를 검사 할 수 있습니다. printf와 비교하여 런타임에서 상태를 출력 할 위치를 선택할 수 있습니다.

공격적인 환경에 배포 된 Adobe Flash 응용 프로그램을 디버깅 할 때 많은 도움이되었습니다 . 각 중단 점에서 필요한 상태를 인쇄하고로 콘솔 디버거를 시작한 다음 fdb | tee output.log일부 중단 점을 수행하는 일부 조치를 정의하기 만하면 됩니다. 그런 다음 다른 중단 점의 상태를 철저히 비교하여 로그를 인쇄하고 정보를 분석 할 수 있습니다.

안타깝게도 GUI 디버거에서는이 기능 (파일에 로깅)을 거의 사용할 수 없으므로 개발자가 헤드의 객체 상태를 비교할 수 있습니다.

그건 그렇고, 내 의견은 디버거를 쳐다보기 전에 디버깅 할 위치와 무엇을 계획해야한다는 것입니다.

또 다른 것은 새로운 오래된 프로젝트에 참여하고 아무도 코드가 수행중인 작업을 실제로 알지 못하면 변수 / 객체 /를 반향하여 디버깅 할 수 없다는 것입니다 ... b / c 코드가 무엇인지 전혀 모릅니다 전혀 실행되었습니다.

내 직업에서 나는 정확히 그런 종류의 상황에 직면하고 있으며 시각적 XDebuging은 무슨 일이 일어나고 있고 어디에 있는지에 대한 아이디어를 얻는 데 도움이됩니다.

친애하는

라파엘

이미 언급 한 많은 것들 외에도 printf에 비해 디버거의 가장 중요한 장점 중 하나는 printf 문을 사용하면 버그가있는 기능을 알고 있다고 가정한다는 것입니다. 대부분의 경우 그렇지 않은 경우 현지화를 위해 몇 가지 추측을하고 다른 많은 함수에 print 문을 추가해야합니다. 버그는 프레임 워크 코드에 있거나 생각했던 곳에서 멀리 떨어진 곳에있을 수 있습니다. 디버거에서는 중단 점을 설정하여 코드의 다른 영역과 다른 시점의 상태를 검사하는 것이 훨씬 쉽습니다.

또한 적절한 디버거를 사용하면 조건과 작업을 중단 점에 연결하여 printf 스타일 디버깅을 수행 할 수 있으므로 코드를 수정하지 않고도 printf 디버깅의 이점을 계속 유지할 수 있습니다.

IDE에서의 디버깅은 공유 호스트와 같은 오류 로그 및 셸 액세스가 불가능한 환경에서 매우 중요합니다. 이 경우 원격 디버거가있는 IDE가 view stderr또는 과 같은 간단한 작업을 수행 할 수있는 유일한 도구입니다 stdout.

print 문을 사용할 때의 문제는 코드가 엉망이된다는 것입니다. IE에는 10 개의 파트가있는 함수가 있으며 어딘가에서 충돌하는 것을 알고 있지만 어디 있는지 확실하지 않습니다. 따라서 버그가있는 위치를 정확히 나타 내기 위해 10 개의 추가 인쇄 명령문을 추가합니다. 버그를 찾아서 해결했으면 이제 해당 인쇄 문을 모두 제거하여 정리해야합니다. 어쩌면 당신은 그렇게 할 것입니다. 어쩌면 잊어 버릴 것이고 결국 프로덕션에서 끝나고 사용자 콘솔에는 디버그 인쇄가 가득합니다.

와우,이 질문이 마음에 드십니까? 나는 그것을 감히 감히하지 않았다 ...

사람들은 다른 방식으로 일하는 것 같습니다. 나에게 가장 효과적인 것은 다음과 같습니다.

• 메모리 관리를 포함하여 내 코드의 탄탄한 마인드 모델 보유
• 발생하는 상황을 추적하기 위해 계측 (예 : 인쇄 문) 사용

저는 40 년 이상 일상 생활에서 C ++ 및 Python의 사소한 기술 및 과학 응용 프로그램에서 일하면서 경력을 쌓았으며 디버거가 나에게 도움이되지 않는 개인적인 경험을 가지고 있습니다.

나는 그것이 좋다고 말하지 않습니다. 나는 그것이 나쁜 말을하지 않습니다. 그냥 공유하고 싶습니다.

단지 디버깅이 아닙니다. IDE를 사용하면 여러 가지 방법으로 더 나은 소프트웨어를 더 빠르게 구축 할 수 있습니다.

• 리팩토링 도구
• 지능적으로 API를 더 쉽게 발견 할 수있게하거나 친숙한 항목의 정확한 철자 / 사례를 상기시킵니다.
• 변수 및 클래스 이름을 자동 완성하여 입력 비용 절감
• 컴파일을 시작하기 전에 특정 종류의 오류를 찾으십시오.
• 변수 / 메소드 / 클래스 선언 / 정의는 동일한 파일이나 폴더에 있지 않더라도 자동으로 이동합니다.
• 처리되지 않은 예외 처리

계속할 수있었습니다.