실제 프로그래머는 디버거를 사용합니까? [닫은]


15

숙련 된 프로그래머가 실제로 디버거를 사용하고 있다면 어떤 상황에서든 사용하십시오. 그 질문에 대한 답변에서 나는 "개월"이라고 말했지만 아마도 "년"을 의미했을 것입니다-나는 정말로 디버거를 사용하지 않습니다. 그래서 내 대답은 당신이 어떤 상황에서 숙련 된 프로그래머로서 디버거를 사용하겠습니까?


14
숙련 된 프로그래머가 키보드를 사용하고 있는지 묻는 것과 같습니다. 키보드와 관련된 경험을 이해하지 못합니다. 그들이 신이라고 생각하고 처음부터 오류없이 완벽한 작동 코드를 작성하십니까? 그리고 그것이 당신에게 어떤 의미가 있더라도-필요할 때 디버거 사용을 중단하고 다음과 같이 말하십시오. 나는 어떤 전문가가 그런 질문에 대답 할 지 의심합니다 ...

3
@ Wool : "경험이 풍부한 프로그래머가 디버거를 사용하십시오"라는 기본적인 질문은 좋은 질문입니다. 실제로 그것이 미니 거룩한 전쟁을 시작했다는 사실에 놀랐습니다.
케빈

19
물론 실제 프로그래머는 나비를
Rein Henrichs

4
대부분의 기존 디버거는 구식이며, 엉터리 인터페이스를 가지고 있으며, 프로그래머는 마스터하기 어려운 개념과 패러다임을 알고 이해해야하며 오늘날 대부분의 프로그래머가 사용하거나 알기를 기대하지 않습니다. 결과적으로, 대부분의 현대적이고 숙련 된 프로그래머는 경험의 고통을 피하기 위해 디버거에서 거의 디버깅 할 필요가없는 코드를 작성하는 데 필요한 기술을 배우기 위해 많은 노력을 기울입니다. 따라서 "그렇습니다."그리고 "가능한 한 적게"
blueberryfields

7
"디버거를 사용하지 않는"숙련 된 프로그래머는 아마도 gdb / SoftICE의 관점에서 생각하고 실제 통합 디버거를 사용한 적이 없습니다 (그리고 아마도 그 문제에 대해 IDE를 사용하지 않을 것입니다). 그들은 고통스러운 시대보다 훨씬 뒤에 있습니다.
BlueRaja-대니 Pflughoeft

답변:


44

디버거를 사용하지 않는 것은 경험이 없다는 표시입니다. 코드를 한 줄씩 단계별로 실행하는 것이 실행 흐름을 추적하는 가장 좋은 방법입니다.


30
이상하게도 어셈블러, 포트란, C, C ++ 등에서 30 년 이상 프로그래밍 한 후에는 하나도 사용하고 싶지 않습니다.

59
오랫동안 무언가를한다고해서 반드시 좋은 것은 아닙니다.
ceejayoz

31
하지 할 수있는 디버거를 사용하는 것은 경험 부족의 표시이다. 코드를 읽는 것만으로 프로그램의 흐름을 이해하는 것은 아닙니다. 물론, 숙련 된 프로그래머에게는 가끔 디버거가 필요하지만 코드를 읽을 수 있으면 디버깅 할 필요가 없으며 디버깅 프로세스를 더 빠르게 수행 할 수 없습니다.
GolezTrol

10
@ 칼 빌레펠트 (Karl Bielefeldt) : 디버깅에 디버거를 사용하지 않는 몇 가지 유명한 프로그래머의 예를 들겠습니다. Linus Torvalds, Linux의 저자. Larry Wall, Perl의 저자. 당신을 위해 충분한 소프트웨어?
btilly

9
@Neil : 자신의 코드 작업에 얼마나 많은 시간을 소비하고 다른 사람들이 작성한 코드를 얼마나 많이 유지 관리합니까? 그리고 특히 프로그래밍 언어 근처에서 허용되어서는 안되는 다른 사람들이 작성한 코드를 얼마나 많이 유지합니까?
Carson63000

28

큰 시스템에서 작업하기 때문에 디버거를 자주 사용하기 때문에 짜증이납니다. http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html

코드를 얼마나 짧고 자주 읽는지에 관계없이 항상 버그가있을 가능성이 있습니다. http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

오류는 인간이며 프로그램이 올바른지 결코 증명할 수 없으므로 디버거 / 자동 테스트와 같은 도구를 사용하여이 어려운 비즈니스에 도움이되지 않겠습니까?

코드가 짧으면 간단한 테스트를 수행합니다. 또한 짧고 버그의 특성을 알고 있다면 코드를 읽는 것으로 충분할 수 있습니다. 그러나 코드 기반이 크면 여러 언어와 함께 3 개의 계층이 혼합 된 후 여러 수준에서 우수한 테스트 적용 범위와 매우 우수한 디버거가 필요합니다. 그렇지 않으면 많은 시간이 낭비됩니다.

그렇다면 언제 디버거가 필요하지 않습니까?

나는 가장 똑똑한 코더가 아니며 가장 경험이 많지는 않지만 여전히 디버거를 사용할 필요가 없습니다. 그때는 :

  • 코드는 내 것이거나 잘 작성되었으며 AND
  • 읽을 수있는 언어로 작성되었으며
  • 전체 프로젝트는 작습니다.

언제 디버거에 크게 의존합니까?

  • 짧은 답변 : often .
  • 응용 프로그램이 중단 된 경우 특히 배포 할 때. 해당 컴퓨터에 VS2010을 설치하면 "알 수없는 오류"와 FileNotFoundException.
  • 타사 라이브러리가 충돌하거나 오작동하는 경우
  • 코드가 잘못 작성된 경우 특히 지난 10 년 동안 10 명의 다른 사람이 동일한 파일을 건 드리면 그 중 7 명은 더 이상 회사에 없습니다.
  • 프로젝트가 큰 경우
  • 코드가 모 놀리 식일 때.
  • 여러 계층 (GUI, SQL, BL)이 관련된 경우

"디버거"는 둘 이상의 도구를 나타낼 수 있습니다. Visual Studio 디버거, SQL 디버거 (주로 저장된 procs) 및 SQL 프로파일 러 (SP가 호출되는 것을 파악하기 위해)를 사용합니다. 빠른 sysadmin-ish Python 스크립트를 작성하는이 도구의 도구가 필요합니까? 아니요. GUI 기반 도구를 직접 만든 경우? 다릅니다. .Net WinForms 인 경우-아마도 아닙니다. 그것이 WPF라면-그렇습니다.

어쨌든 "실제"프로그래머를 정의하는 것은 무엇입니까? 빠른 것? 지식이 있습니까? 알고리즘에 능숙합니까? 좋은 문서를 작성합니까? 언제이 새로운 타이틀을 정확히 졸업했을까요? 마법의 선은 언제 교차합니까?

기존의 100 년 이상의 노력으로 자신의 손을 더럽 히지 않은 프로그래머는 복잡성과 자신의 한계 (코드 품질에 좌절)에 의해 겸손해질 기회가 없었다고 말할 수 있습니다.

나는 개인적으로 사용 가능한 최고의 디버거를 사용하려고 시도하고 자주 사용하는 경향이 있습니다. 작업이 충분히 간단하고 디버거가 필요하지 않은 경우 사용하지 않습니다. 내가 필요한지 아닌지를 파악하는 데 너무 오래 걸리지 않습니다.

...

이제 이론적으로는 코드베이스를 오랫동안 읽을 수 있었으므로 얻을 수있었습니다. 그러나 실습 방식이 가장 효과적이며, 종종 내가보고있는 어리석은 코드를 다시 작성하고 싶습니다. 불행히도 내가있는 코드 기반을 정리하는 데 10 년 이상이 걸렸습니다. 따라서 디버거를 사용하는 것이 첫 번째 단계입니다. 5 백만 줄의 코드 중 하나만 작동하는 것을 발견 한 경우에만 파일을 위아래로 스캔하여 해당 클래스가 수행하는 작업을 파악하려고합니다.


+1, 훌륭한 답변, 특히 "여러 계층이 관련되어있을 때"측면에 동의합니다. "코드를 읽고 오류를 찾는 것"에서 거의 언급하지 않습니다.
Carson63000

모든 것을 읽을 수있어서 다행입니다.
Job

큰 답변과 "실제 프로그래머"의 정의를 살펴보면 +1입니다. 이 문구를 사용하면 OP 교활하고 흥미롭고 잠재적으로 염증을 일으켰습니다 (암시 적 의미 또는 병력을 부정하기 때문에).
Smandoli

1
"프로그램이 옳다는 것을 결코 증명할 수는 없습니다"사실이 아닙니다.
GManNickG

1
@GMan, 성명을 자세히 설명하십시오. 내가 배운 바와 같이, 특정 언어에 대한 짧은 코드 스 니펫의 정확성을 입증하려는 많은 이전의 시도는 실패했다. 예를 들어 증명이 완료된 후 몇 가지 버그가 발견되었다. 매우 사소한 일부 프로그램이 올바른 것으로 입증 될 수 있다고 생각합니다. 나는 당신의 각도를 여기서 궁금합니다.
Job

17

"디버거가 마음에 들지 않습니다. — 리누스 토발즈

반면에 그는 스택 오버플로 계정이 없으므로 그의 의견에 관심이 있는지 확실하지 않습니다. :)


3
우리 중 많은 사람들이 Linus Torvalds가 아니며, 나머지 사람들은 단지 인간이기 때문에 디버거가 필요합니다.
Nodey The Node Guy

7
커널은 디버거에 잘 맞지 않습니다.

7
예, 커널 프로그래밍은 사용자 공간 프로그래밍과 다른 분야입니다. 나는 일반적으로 사용자 공간에 대한 Linus의 의견에 동의하지 않지만 커널 공간을 다룰 때 분명히 존중 할 수 있습니다.
대안

16
"디버거를 좋아하지 않는다"는 것이 "디버거를 사용하지 않는다"는 의미는 아닙니다. Linus가 실제로 말한 것은 "디버거가 마음에 들지 않습니다. 절대로, 절대 그런 적이 없을 것입니다. 항상 gdb를 사용하지만, 디버거로 사용하는 것이 아니라 프로그램 할 수있는 스테로이드의 디스어셈블러로 사용하는 경향이 있습니다." (나는 Linus가 디버거를 사용하지 않는다는 것을 의미하기 위해 그것을 왜곡하려고 노력하지만 그것은 정확하지 않습니다.)
Kristopher Johnson

6
Linus Torvalds처럼 보이며 전혀 동의하지 않습니다.
BlueRaja-대니 Pflughoeft

12

그래서 내 대답 은 당신이 어떤 상황 에서 숙련 된 프로그래머로서 디버거를 사용하겠습니까?

  • 코드 를 읽어 "디버그"할 수없는 경우
  • 주어진 시간에 어떤 변수가 어떤 값을 가질 지 예측할 수 없을 때.
  • 코드 의 정신 모델 이 코드에서 제공 한 출력에 맞지 않을 때

편집하다:

프로그래밍 과정에서 디버거를 사용하는 방법을 모른다는 점이 많았습니다. 따라서 과거에는 디버거없이 디버깅해야했습니다. 그러나 디버거를 사용하는 법을 배우고 나면 버그를 찾는 데 100 배 더 생산성 이 높아 졌습니다.


"코드의 정신 모델이 코드가 제공 한 출력에 맞지 않을 경우"+1
사용자

8

현재 답변과 약간 다른 관점을 제공합니다. 종종 실시간 구성 요소가있는 시스템에서 작업하는 임베디드 소프트웨어 엔지니어로서 디버거는 거의 사용하지 않습니다.

때때로 디버거는 놀라운 도구가 될 수 있으며 데스크탑에서 코드를 빌드하고 실행할 수있을 때마다 항상 디버거를 사용합니다.

실시간 제약 조건을 가진 칩에서는 디버거를 사용하는 것과 관련된 큰 부담이 있습니다. 실행을 일시 중지하자마자 나머지 시스템의 타이밍이 치명적일 수 있습니다. 일반적으로 온칩, 중요하지 않은 코드의 printf 및 시간이 중요한 코드의 IO 흔들림이 가장 훌륭하고 실제로 가장 간단한 도구입니다. 디버거만큼 좋지는 않지만 실제 시스템으로 작업하는 것이 훨씬 저렴합니다.


1
하드웨어 기반 디버거 보드를 조사하고 싶을 수도 있습니다
Steven A. Lowe

@ 스티븐 감사합니다; 불행히도 내가 작업하는 일부 시스템은 적절한 하드웨어 지원을 제공하지만 다른 시스템은 지원하지 않습니다. 일반적으로 로직 애널라이저 옵션이 있지만 시간면에서 훨씬 비쌉니다.
Luke Graham

나는 정반대입니다. 임베디드 시스템에서 디버거를 훨씬 더 자주 사용합니다. 그래도 타이밍을 뒤집는 것에 동의합니다. 디버거를 루프에 배치하여 발생하는 변경 사항을 필터링 및 / 또는 최소화하려면 상당한 노력이 필요합니다.
Karl Bielefeldt

7

숙련 된 프로그래머는 필요할 때 거의 독점적으로 디버거를 사용한다고 생각합니다. 실제로 코드 실행을 따르는 것보다 버그를 추적하는 더 좋은 방법은 무엇입니까?

당신은 세계의 스키트가 실수하지 않거나 모든 것을 알고 있다고 가정합니까? 가장 사소한 프로그램을 제외한 모든 프로그램은 일부 상황에서 예기치 않은 방식으로 작동합니다. 문제를 조사해야 할 것입니다. 따라서 선택은 스펙트럼의 한쪽 끝에서 인쇄 설명을 사용하거나, 코드가 실행될 때 발생하는 문제를 검토하거나, 다른 쪽에서 모템을 게시하거나, 중간에서 오른쪽을 살펴보고 진행 상황을 파악하는 것입니다.

아마도 더 좋은 방법은 숙련 된 프로그래머가 언제 디버거를 사용해야하는지 아는 것입니다. 스택 추적을 보는 종속성이 거의없는 코드에서는 무엇이 잘못되었는지 파악하기에 충분합니다. 그러나 코드가 다른 코드와 작동하는 복잡한 시나리오가 있으며 작성하지 않은 내용을 보려면 디버거가 필요합니다.


4
글쎄, 이것은 내가 조사하려고하는 것입니다. 나는 매우 숙련 된 프로그래머이며 결코 사용하지 않습니다.

5
@neil, 아마도 당신은 필요가 없습니다. 안심하십시오. 디버거가 문제를 해결하는 가장 간단한 방법이 될 시간이 올 것입니다. 실제로 하나를 사용하여 종료
하든 말든

내가 쓰지 않은 것을 읽을 수 있습니다. 그리고 내가 할 수 없다면 나쁜 코드이기 때문에 유용합니다. 다른 경우에는 디버거를 사용합니다.
GolezTrol

사용하는 언어가 예외를 지원하고 예외를 사용하는 경우 + 로깅 프레임 워크 (예 : log4j 또는 이와 유사한 것)를 적절하게 사용하면 항상 오류 라인을 가리키는 스택 추적으로 끝납니다. 99 %는 예상치 못한 널 포인터 예외입니다. 디버거가 다른 말을 할 것입니까? 이제 c로 프로그래밍 할 때 디버거 없이는 찾을 수 없었던 것들이있었습니다 (예 : 스택 손상). 그러나 이런 종류의 일들은 더 이상 고급 언어에서는 일어나지 않습니다.
케빈

1
@ kevin, 맞습니다. 디버거가 가장 자연스럽게 문제를 해결할 수있는 두 가지 방법 사이에 문제가 있다고 생각합니다. 어쩌면 grails와 같은 동적 언어 프레임 워크에서 객체에 적용된 동적 속성을보고 싶습니다. 어쩌면 내가 생각하지 않는 것이 null이 아닌 곳을 정확하게보고 싶을 수도 있습니다 (NPE는 예외가 어디에 있는지, 왜 null이 아닌지를 알려줍니다). 어쩌면 디버거가 예외시 일시 중지되어 스택 추적에서 발생한 것이 아니라 예외를 일으킨 코드 조합을 볼 수 있습니다.
hvgotcodes

4

나는하지 않고 10 년 이상 프로그래밍 해 왔습니다. 나는 c / c ++로 프로그래밍 할 때 사용했다. 이제 자바로 프로그래밍합니다. 진실은 당신이 올바르게 로깅을하고 있다면 대부분의 숙련 된 개발자에게 충분한 스택 추적으로 끝날 것입니다. 또한 (좋은) 단위 테스트와 기능 테스트를 작성하면 전체 버그를 제거 할 수 있습니다.


더 명확히하면 디버거를 사용하는 많은 Java 프로그래머를 알고 있습니다. 그들은 대부분 학교 밖입니다.
케빈

1
stacktraces에는 데이터가 표시되지 않습니다. 직접 정보를 추가해야합니다. 그러나 순금입니다.

1
@ Thorbjørn : 실제로 데이터 표시 할 수 있습니다 . 예를 들어 Python의 cgitb 모듈을 참조하십시오 . (이름의 CGI는 대부분 흔적 적이며, CGI가 충돌했을 때 사용 가능한 스택 추적을 제공하는 모듈의 원래 목적이었습니다.) 물론, 너무 많은 데이터를 가져 와서 스택으로 이동하기가 어려워지는 경우가 있습니다. 관심 프레임. cgitb.enable(format='text')어쨌든 사랑 합니다.
SamB

디버거를 사용하지 않고 C ++를 사용합니다.
Nikko

@SamB Kevin은 Java에 대해 이야기했지만 그렇게 할 수 없습니다

4

무슨 상관이야? 내가 알고 싶은 것은 디버거를 사용하면 장기적으로 더 나은 프로그래머가되는 것을 막을 수 있습니까? 많은 숙련 된 개발자가 시작했을 때 디버거의 품질이 떨어졌을 수 있습니다. 더 깊은 이해를 방해하는 목발입니까?

다른 프로그래머보다 아마도 더 좋은 일부 프로그래머는 디버거가 필요하다는 것을 알았고 (첫 번째를 만든 사람은 아무도 모릅니다). 그 결과 더 생산적이라고 확신합니다. 더 적은 필사자들이 코드를 작성하도록 동기를 부여한 것이 의심 스럽다.


3

드물게.

당신의 방법은 마음에 의해 컴파일되고 실행될만큼 작고 단순해야하며, 단위 테스트는 기능을 포함해야합니다. 버그를 발견하면 테스트를 작성하십시오. 실행하고 수정하십시오.

ASP.NET 프레임 워크와 같이 테스트 할 수없는 코드에서 예기치 않은 동작이 발생했을 때 디버거를 사용하는 경향이 있습니다.


3
...이 스레드에서 진짜 증오의 noobs에를 프로그래머

2
이것을 투표 할 이유가 없습니다-그는 옳습니다.
wadesworld

11
-1이 주장은 Vegas에서 돈을 버는 방법은 모든 손을이기는 것이라고 말하는 것과 같습니다. 그것은 상황의 현실을 반영하지 않으며 모든 코드가 단순하다는 주장은 작은 고립 된 문제에만 존재합니다. 또한 "실행, 수정"주장은 수정 방법에 대해 완전히 무시합니다. 나는 그것을 슬라이드하게하려고했지만 동의하지 않는 모든 사람들이 그것을 다운 보팅 할 가치가 있다고 비난했다.
whatsisname

2
-1 : "당신의 방법은 작고 단순해야 마음에 의해 컴파일되고 실행될 수 있습니다"는 현실과 분리되어 있습니다. 20 줄보다 긴 함수가 너무 길다는 것과 같습니다. 무의미한 말.
John Dibling

3

스몰 토크에서는 거의 전적으로 디버거를 개발 합니다.

  1. 내가 실패 할 것이라는 테스트를 작성하십시오.
  2. 테스트를 실행하십시오. 실패하면 디버거가 나타납니다.
  3. 디버거에서 테스트를 통과하는 데 필요한 코드를 작성하십시오.
  4. 실행을 재개하십시오.
  5. 녹색 표시등이 켜지면 새로운 테스트 실패로 1 단계로 이동하십시오. 그렇지 않으면 디버거에서 내가 잘못한 것을 찾아서 수정하십시오.

2

필요할 때 디버거를 사용합니다. 그것은 매일이 아니지만 때때로 발생합니다. 정확한 결과를 확인하기 위해 코드를 단계별로 실행하는 것이 더 나은 경우가 있습니다.

디버거를 점점 적게 사용한다는 것을 인정해야합니다. 델파이에서 10 년 이상 개발해 왔습니다. 또한 PL / SQL로 저장 프로 시저를 작성합니다. 몇 달 이래로 저는 PHP 개발자이기도합니다.

몇 년 전에 작성된 불분명 한 코드를 발견하고 수정 해야하는 경우 주로 이러한 경우 중 하나에서 디버거를 사용합니다. 코드를 읽기 어려운 경우 프로그램이 작동하는 정확한 방법을 찾는 데 도움이되는 경우가 있습니다. PHP는 거의 필요하지 않지만 이벤트 기반 인 Delphi에서는 복잡한 프레임 워크를 얻었을 때 도움이됩니다.

그러나 당신이 말했듯이 디버거를 사용하는 것은 예외입니다. 대부분의 문제는 코드를 읽고 실수 (또는 다른 사람)가 저지른 실수를 수정하면 해결됩니다.

그러나 그것은 코드를 단계별로 진행합니다. 예외가 발생하면 호출 스택을 자주 사용하고 때로는 변수를 검사하기 위해 중단 점을 배치합니다. 그러나 어쨌든 철저한 리팩토링이 필요한 코드가 거의 항상 있습니다.


2

나는 때때로 디버거없이 코드를 작성하지만, 총구에 가해질 때만, 즉. 8051 또는 Z80의 레거시 임베디드 건지.

IMHO, 복잡한 작업에 디버거와 로깅이 필요합니다. 한 번은 다른 것을 대신하지 않습니다. 예를 들어 코드가 수행 할 수있는 유일한 작업은 하드웨어와 상호 작용하고 세마포어를 설정하는 것만으로도 앱이 드라이버에 포함되어 있으면 로깅 시스템이 도움이되지 않습니다.

디버거는 작성한 방식에 따라 앱이 제대로 작동하는 시스템 오류를 도울 수 없지만 간헐적 인 통신 프로토콜 오류로 인해 시스템이 여전히 작동하지 않습니다.

따라서 어리 석고 눈부신 버그와 하드웨어 콕업을 제거하려면 디버거가 필요합니다. 간헐적 인 시스템 통합 버그를 포착하려면 좋은 로깅이 필요합니다.

나는 둘 다 가지고 있어야한다 – 나는 내가 얻을 수있는 모든 도움이 필요하다!


2
z80은 디버거에 충분합니다. CP / M에는 ZSID가있었습니다.

1

이 단계가 실패 할 때만 디버거를 사용합니다.

  1. 재현 가능한 오류를 얻으십시오. 생각한다. 이것은 종종 필요한 전부입니다.
  2. 스택 추적 및 로그를 확인하십시오.
  3. 문제가되는 코드 주위에 더 많은 로깅을 추가하십시오.

이 단계는 모든 사례의 95 %를 처리합니다. 즉, 디버거를 거의 사용하지 않으며, 사용할 때 너무 많은 정보 를 제공하는 경향이 있습니다. 있으며 관련이없는 세부 사항 혼란에 빠집니다. 다중 스레드 실시간 시스템에서 작업하는 경우 특히 그렇습니다.

따라서 신중하게 배치 된 로깅 문은 먼 길을갑니다.


1

숙련 된 프로그래머가 아주 오래된 프로그래머와 동일하고, 디버거를 항상 사용할 수 없었던 때로, 때로는 그리 좋지 않은 경우에 프로그래밍을 배우고 습관을 형성했을 수 있을까요?

printf 디버깅에 능숙하다면 (그리고 80 년대에 우리는 선택의 여지가 없었지만 실제로는 능숙 ​​해졌다), 디버거가 그렇게 많이 추가하지 않았을 것입니다.


0

개인적인 선택의 문제입니다.

솔직히 나는 디버거가 특정 프로그램 실행 단계에서 램에 무엇이 있는지 아는 데 도움이되는 특정 상황에서 유용하다고 생각합니다.

디버거의 기본 유틸리티는 프로그램을 중지하지 않고 프로그램을 중지하는 것입니다.이 기능은 매우 중요합니다.

이 두 가지 기능 외에도 디버거가 실제로 필요하다고 생각하지 않습니다. 복잡한 프로그램은 일종의 "verbose"모드를 가져야합니다. 즉, printf 또는 std :: cout으로 수행하는 모든 작업, 수행 한 선택 사항 및 기타 여러 매개 변수를 알려줍니다.

프로그램을 만들었을 때 사용자가 프로그램을 사용하는 데 문제가 있다고 상상해보십시오. 프로그램을 사용하도록 설계된 방식으로 사용하고 있는지 또는 그가 불평하는 것이 버그 일 수 있는지 아는 방법은 무엇입니까?

디버거는 자동차의 전기 조향과 같습니다. 차를 두는 것이 더 편하지만 드라이브가 더 나아지지는 않습니다.

Progamming은 디자인과 논리에 관한 것입니다. 도구가 물건을 추적하는 데 도움을 줄 수있는 방법은 더 나은 프로그래머가되지 않습니다.

또한 디버거는 컴파일 된 언어에 유용하며, 해석 된 언어에는 훨씬 적습니다.


2
컴파일 된 대 해석 된 것과 관련이 무엇인지 이해하지 못합니다.
Michael Burr

좋은 질문입니다. 나도 마찬가지입니다.
jokoon
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.