IDE없이 어떻게 디버깅합니까? [닫은]


61

IDE를 찾을 때마다 (현재 Go와 함께 고민하고 있습니다) Vi, Emacs, Notepad ++ 등을 추천하는 사람들로 가득 찬 스레드를 찾습니다.

IDE 외부에서 개발 한 적이 없습니다. 내가 망친 것 같아 IDE없이 어떻게 디버깅합니까? 로깅만으로 제한되어 있습니까?


53
내가 아는 한 Oldschool printf 스타일 디버깅 :-)
Andrew Walters

25
IDE 이전에는 실행중인 프로세스에 연결되거나 프로세스를 래핑 한 디버거를 사용하여 프로그램 상태를 스테핑 또는 검사 할 수있었습니다. (gdb, perl -d 등 ...) 디버거를 IDE에 통합하면 편리하지만 별도로 존재합니다. 디버거 실패, 로깅 ... 그러면 로깅이 프로그램이 회수 될 때 프로그램의 상태가 변경되지 않도록하고 발견하려는 버그를 다시 소개합니다.

7
커맨드 라인 디버거, (여러 IDE 디버거가 그것들을 기반으로 함)
ratchet freak

14
천천히 조심스럽게
FrustratedWithFormsDesigner 2018 년

3
인쇄물은 일반적으로 사용되지만 경쟁 조건과 같이 더 미묘한 버그를 숨길 수 있습니다.
James

답변:


86

디버거를 사용합니다. 대부분의 경우 이것은 IDE가 배후에서 수행하는 작업이기도합니다. GUI의 경험을 감싸는 것입니다.

Unix에서 가장 일반적으로 사용되는 디버거 중 하나는 GNU gdb이며, 이는 이전의 Unix 디버거 (예 :)를 대체했습니다 dbx.

명령 행에서 디버깅의 모양과 느낌에 대한 아이디어를 얻으려면 gdb 매뉴얼을 참조하십시오 .

다른 영역과 마찬가지로 명령 줄에서 디버거를 사용하려면 구문과 명령 집합을 학습해야하지만 많은 유연성과 스크립팅 기능이 필요합니다. 반면 vim 또는 emacs와 같은 편집기에서 작업하는 것이 편한 경우 즐겨 사용하는 편집기에 즐겨 사용하는 디버거에 대한 플러그 인이있을 수 있습니다.


18
"디버거를 사용하여"+1 IDE의 I는 "Integrated"의 약자 :)
joshin4colours

1
파이썬으로 작성하면 pdb실제로 내가 찾은 IDE 디버거보다 낫습니다.
asthasr 2012 년

1
@syrion 그리고 ipdb그것보다 낫다;)
Izkata

훌륭합니다. Izkata가 존재한다는 것을 몰랐습니다. 감사.
asthasr

@ joshin4colours 통합! = 수집, 아니?
Cole Johnson

35

그래픽 드라이버를 작성하는 동안 몇 년 동안 디버거를 사용했습니다. 그래픽 컴퓨터가 고장 났을 때 기본 컴퓨터의 화면이 작동하지 않기 때문에 첫 번째 컴퓨터에 대해 디버거를 실행하는 두 번째 컴퓨터가 있습니다. 코드를 중지하고 하드웨어가 걸려있는 지점까지 올라가서 무슨 일이 일어나고 있는지 알 수 있어야했습니다.

순전히 소프트웨어 문제의 경우 문제에 대해 생각하고 문제에 대해 더 많이 알기 위해 시스템을 테스트하는 것이 한 줄씩 코드를 단계별로 실행하는 것보다 훨씬 유용합니다. print 문을 사용하면 명령 줄이나 로그 파일에서 발생한 모든 것을 나열하여 디버거로 할 수있는 것보다 더 쉽게 앞뒤로 이동할 수 있습니다.

가장 어려운 버그는 일반적으로 컴퓨터에서 발생하는 문제를 이해함으로써 해결됩니다. 때로는 종이나 화이트 보드가 있고 때로는 다른 일을하면서 답이 드러납니다. 가장 까다로운 버그는 Where 's Waldo 재생과 같은 코드를주의 깊게 보면 해결됩니다. 나머지는 모두 print 문이나 logging 문으로 가장 쉬운 것처럼 보입니다.

사람마다 스타일이 다르며 작업마다 다른 스타일이 더 좋습니다. 인쇄 문이 반드시 디버거에서 내려진 것은 아닙니다. 당신이하고있는 일에 따라 더 나아질 수 있습니다. 특히 네이티브 디버거가없는 언어 (Go?)


7
이. 물론입니다. 나는 적어도 나에게 문제는 디버거가 더 이상 눈에 띄지 않는 논리 오류 또는 상호 작용 인 경향이 있음을 발견했다. 무엇 뿐만 아니라 잘못되고 있는지 이해해야 합니다 .
가짜 이름

2
+1 전체에 대한 going backwards. 나는 종종 경험이 : "이봐 - waittaminute이 오른쪽 값이 아닌 않은 방법 ?"하고 코드를 읽는 동안 출력에왔다 갔다해야합니다. 디버거는 거꾸로 나쁘다.
Izkata

그렇다. gdb는 덤프 된 코어를 검사하는 데는 좋지만, 그런 상황에서 나는 인쇄 문을 사용하는 것이 실제로 도움이된다는 것을 알았다.
Brian

디버거는 유용하지만 임시입니다. 좋은 로깅 프레임 워크를 사용하면 디버깅 세션을 구축 할 수 있습니다. 디버거를 사용하여 상황을 이해하고 print 문으로 보완하여 디버깅 세션을 영구적으로 만듭니다. 나는 시간이 지남에 따라 디버거를 점점 더 적게 고소하고 점점 더 생산적으로되었다는 것을 발견했다
Newtopian

예, 종이나 화이트 보드로 생각하거나 마음 속으로 생각하는 것이 디버깅하는 가장 좋은 방법입니다. 종종 사고 과정을 수정합니다. 디버거는 때때로 프로그램에서 버그가 발생하는 원인에 대한 원래의 문제를 해결할 수없는 쉬운 방법입니다 :)
Nishant

11

어떤 사람들 은 커맨드 라인에서 gdb 를 사용 하거나 플러그인을 사용 합니다. DDD 와 같이 gdb에 대한 독립형 GUI 프론트 엔드도 있습니다 . 당신의 언어에 따라 특정 언어 독립 실행 형 디버거와 같은 GUI를,있다 Winpdb 파이썬, 또는 jswat 자바에 대한이. 이러한 프로젝트 는 디버깅 에만 중점을두기 때문에 통합 디버거보다 우수합니다.

IDE에 대한 다른 작은 비밀은 사용자 정의 편집기를 지정할 수있는 가치가 있다는 것입니다. 따라서 특정 작업에는 IDE의 일부를 사용할 수 있지만 편집에는 괜찮은 편집기를 사용할 수 있습니다. 디버거를 사용하기 위해 IDE를 시작하는 것은 드문 일이 아닙니다. 특히 동료가 모두 사용하는 경우에는 특히 그렇습니다.


1
+1 물론 다른 옵션은 : IDE의 편집기에 색상과 keybinds을 설정하고 척하는 것입니다
darvids0n

1
@ darvids0n, 나는 20 년이 넘는 기간 동안 IDE를 사용 해 왔으며, 아마도 언젠가 내일 언젠가는 다음 세기 언젠가는 시도를 시도하는 것에 대해 생각할 수 있음을 암시하는 편집기를 가진 편집기를 찾기 위해 YET을 가지고 있습니다. GNU Emacs에 촛불을 들고
John R. Strohm

6

일부 언어는 REPL을 제공합니다. 즉, 코드를 작성할 때 한 줄씩 코드를 작성하고 실행할 수 있습니다. 이는 코드를 확인하는 첫 번째 단계 일 수 있습니다. 이들 중 다수는 디버깅 기능도 제공합니다. Haskell 용 GHC는 GHCi와 함께 제공되며 IDE와 마찬가지로 명령 행에서 프로그램을 대화식으로 디버깅하는 데 사용할 수 있습니다.


2

printf 문을 사용하여 디버깅에 혐오감을 느끼는 이유를 이해하지 못합니다. 프로그램을 다시 컴파일하고 링크하는 데 시간이 너무 오래 걸렸지 만 오늘날에는 몇 초 밖에 걸리지 않습니다. cout, printf, qDebug () 등의 출력 유형을 사용하여 디버깅하는 것이 매우 쉽다는 것을 알았습니다. Printf 문은 프로그램이 수행 한 모든 작업의 ​​실행 기록을 제공하므로 사실 후에 분석 할 수 있지만 디버거에서 실행하면 프로그램 실행시 수동으로 프로그램 흐름을 기억해야합니다. printf를 사용하면 변수 값을 특정 단위로 변환하고 16 진수, 10 진수 등으로 표시 할 수 있습니다. printf 문은 루틴 및 변수 이름과 행 번호를 나열 할 수 있습니다. 다른 변수에 따라 특정 배열 요소 만 나열 할 수 있습니다. 지시를 따를 수 있습니다. 출력을 매우 쉽게 제어 할 수 있습니다. 카운터에 넣고, 루프를 통해 특정 시간 만 인쇄하고, 디버깅 할 때 print 문을 추가 및 제거하고, 디버깅 출력 수준이 다르고, 파일에 쓰는 등의 작업을 수행하는 것보다 프로그램 기록을 보는 것이 훨씬 쉽습니다. 수동으로 밟은 모든 장소를 기억하고 프로그램이 수행 한 작업을 찾기 위해 시간이 지남에 따라 변수의 내용을 기록해야 할 수도 있습니다. 마지막으로 printf 문을 사용하면 향후 디버깅을 위해 영구적으로 켜고 끌 수 있습니다. 수동으로 밟은 모든 장소를 기억하고 프로그램의 내용을 찾기 위해 시간이 지남에 따라 변수의 내용을 기록 해야하는 것보다 파일에 기록 된 프로그램 기록을 보는 것이 훨씬 쉽습니다. 완료했습니다. 마지막으로 printf 문을 사용하면 향후 디버깅을 위해 영구적으로 켜고 끌 수 있습니다. 수동으로 밟은 모든 장소를 기억하고 프로그램의 내용을 찾기 위해 시간이 지남에 따라 변수의 내용을 기록 해야하는 것보다 파일에 기록 된 프로그램 기록을 보는 것이 훨씬 쉽습니다. 완료했습니다. 마지막으로 printf 문을 사용하면 향후 디버깅을 위해 영구적으로 켜고 끌 수 있습니다.


3
"프로그램을 재 컴파일하고 링크하는 데 시간이 오래 걸렸지 만 오늘날에는 단 몇 초 밖에 걸리지 않습니다." 프로젝트의 언어와 크기에 따라 다릅니다. 현재 프로젝트에서 헤더 파일을 변경하면 256GB RAM이있는 32-CPU 시스템에서 재 구축하는 데 약 65 분이 걸립니다 (농담 아님)
Nemanja Trifunovic

사람들은 print 문으로 디버깅하기위한 "혐오"가 없으며 디버거 만 선호합니다. 나는 printfs를 사용하여 디버깅하지 않는 "디버거 사람"보다 디버거를 사용하지 않는 "printf people"이 훨씬 많다는 것을 알고 있습니다.
Karl Bielefeldt

1
놀랍게도 충분히 분산 된 시스템에 디버거를 사용하는 것은 어렵지만 (시계 동기화 문제로 인해 약간의 부정확 한) 로그를 상관시킬 수 있습니다. 소프트웨어 시스템이 100 개의 서로 다른 컴퓨터에서 실행되는 바이너리로 구성된 경우 디버거를 사용하고 다른 문제가 발생하지 않도록 충분한 잠금 단계로 모든 것을 유지하는 것보다 로그 / "printf 디버깅"이 더 쉬울 수 있습니다.
Vatine

2

jimwise는 이 질문에 아주 잘 대답 했지만 전체 IDE없이 작업하도록 선택하면 Windows 용 Microsoft 제공 명령 줄 디버거는 CDB 라고 덧붙였습니다 . CDB에는 Windows SDK를 다운로드 할 때 GUI에 해당하는 WinDBG 를 포함한 다른 여러 도구가 제공됩니다 .


4
그 질문에 어떻게 대답하는지 자세히 설명해 주시겠습니까?
gnat

당신이 옳습니다. 그 자체로는 질문에 대답하지 않습니다. @jimwise의 대답은이 질문에 대한 좋은 대답이라고 생각했지만 Windows 용 명령 줄 디버거를 찾을 수있는 위치에 대한 정보는 포함하지 않았습니다. 그래서 나는 이것을 가로 질러 Windows에서 어떻게하는지 궁금해하는 사람들을 위해 추가 답변을 고칠 것이라고 생각했습니다. 나는 대답을 많이 말하여 업데이트 할 것입니다.
Drew Marsh

2

나는 보통 몇 주에 한 번씩 디버거를 사용하지 않지만 가장 먼저가는 것은 아닙니다.

내 직업에서 가장 중요한 도구는 너무나 어디에나있어서 거의 언급하지 않은 스택 추적입니다. 스택 추적을 검사하면 발생하는 문제의 90 % 이상을 해결할 수 있습니다. 이 도구는 귀하의 언어에 따라 항상 도움이되는 것은 아니지만, 언어에 의해 잘 구현되면 놀라운 시간을 절약 할 수 있습니다.

간단한 문제를 감지하는 가장 일반적인 두 번째 방법은 아마도 내가 방금 변경 한 코드 일 것입니다. 나는 단위 테스트를 자주 수행하기 때문에 내가 방금 깬 것을 일반적으로 알고 있습니다.

보다 복잡한 개발 및 디버깅을 위해 디버그 또는 추적 수준 로그 문을 추가 할 수 있습니다. 프로덕션 추적 / 디버그 로깅 정보를 배치하는 데 도움이되는 개발 문제를 좋은 안내서라고 생각합니다.

항상 디버거가 유용한 것은 아닙니다. 프로덕션 환경에서는 디버거를 실행하지 못할 수 있습니다 (Heck, 회사의 보안 수준에 따라 로그를 제외하고 프로덕션 시스템에 액세스하지 못할 수 있음). 디버거를 연결하는 데 너무 오래 걸리거나 사용 가능한 좋은 디버거가없는 언어도 있습니다.

로직 및 디버그 / 추적 레벨 로깅을 사용하여 코딩을 모두 수행 한 경우 하드웨어에 액세스하지 않고도 문제를 파악하기 위해 우수한 로그 명령문 (로그 레벨을 증가시킬 수 있음)을 검사하는 경우 일 수 있습니다.

디버거는 강력한 도구라고 생각하지만 도구 상자에서 유일한 도구로 사용하지 마십시오!


1

독립형 텍스트 편집기와 함께 IDE에서 디버거를 사용할 수없는 이유는 없습니다. 나는! Zap을 사용하여 편집하고 JBuilder는 다른 컴퓨터에서 디버깅하고 파일 서버는 지하실에서 사용했습니다. 전통적으로 디버거는 IDE를 따라 드래그하지 않고 독립 실행 형 프로그램이었으며 작동합니다.

포괄적 인 테스트가 디버깅을 대체한다는 점에 주목할 가치가 있습니다. 보고 된 버그를 코드가 아닌 테스트의 버그로 간주하는 것이 좋습니다.

또한 있습니다 printf. 모든 줄에 대해 멈추지 않고 많은 양의 "로깅"을 작성하고 검색하는 것이 유용 할 수 있습니다. -Xbootclasspath/p:Java 라이브러리 클래스를 해킹 하는 등의 방법 으로 프로덕션에서 수정할 수없는 라이브러리 클래스를 수정할 수있는 경우 특히 유용합니다 .


"포괄적 인 테스트가 디버깅을 대체한다는 점에 주목할 가치가 있습니다." - "변위"보다는 감소라고 말하고 싶습니다. TDD를 수행하는 경우에도 디버거를 통해 코드를 실행하는 것이 유리한 경우가 있습니다. 방금 작성한 코드의 수, 그것은 당신이 당신의 이전 테스트
Jules

1

펜과 종이를 사용하거나 문제에 대해 생각하면서 컴퓨터에서 최상의 문제를 해결할 수 있다는 데 동의하십시오. 이것은 라이브 디버거를 사용하는 것보다 더 유용합니다. 종종 사고 과정을 수정합니다.

간단한 사용자 인터페이스를 기반으로하는 콘솔 인 pudb 를 사용할 수 있습니다 . REPL을 입력하고 더 자세히 검사하려면 pdb 또는 ipdb와 같은 선호하는 디버거를 선택할 수 있습니다.

또한 더 포괄적 인 도구 모음을 보려면 PythonDebuggingTools Wiki 를 확인하십시오 .


원래 질문은 Python이 아니라 Go에 관한 것이 었습니다.
TMN

맞아, 나는 어떻게 든 그것을 놓쳤다. 파이썬 디버거를 확인할 때 검색에서 나타났습니다.
Nishant
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.