IT/모바일
제공 : 한빛 네트워크
저자 : Faye Williams
역자 : 김준환
원문 : Debugging for beginners: a response
이 글은 브라이언 맥도날드가 포스팅한 신입 개발자를 위한 디버깅의 후속편이다. 나는 브라이언이 포스팅한 글을 탐독했다. 나는 모든 프로그래머(심지어 10년의 경력이 있어도)들을 가끔씩 성가시게 하는 찾기 힘든 문제들을 찾기 위해 항상 다른 접근법으로 바라보려 노력한다.
아무튼 나는 내가 조금 실망했다는 점을 인정한다. 보다시피, 브라이언은 모든 프로그래머들이 관심을 갖는 주제에 관하여 읽기 쉽고 훌륭한 글을 썼다. 하지만 나는 그의 글에서 어떻게 디버깅을 하는지(더 고급의, 이론적인 레벨보다는), 어떻게 오류를 줄일 수 있는지 대해서 더 적은 초점을 맞추고 있다는 점을 발견했다.
자 그럼, 당신은 오류를 줄이는 최고의 방법은 당신의 코드를 "디버그"하는 것이라 주장(내 남편이 그랬던 것처럼)할 수 있다. 분명히, 당신이 프로그래머로서 경험이 쌓일수록, 잠재적인 위험을 인식하고 방지하는 스킬은 늘어야 하고, 문제들을 해결하기 위해서는 적은 시간을 사용하고 더 많은 시간을 업무를 처리하는데 사용해야 한다.
좋다.
이론적으로, 이 주장에는 두 가지 결함이 있다.
1. 어느 시점에 당신의 소유가 아닌 다른 코드를 디버그 해야 한다.
2. 어느 시점에 당신이 소유한(또는 다른 누군가의) 코드에서 찾기 힘든 버그를 접해야 한다.
브라이언이 명시한 것처럼, 누구도 완벽하지 않으며, 당신의 코드도 완벽하지 않다. 심지어 숙련된 프로그래머가 된다는 것은 더 에러를 잘 찾고 잘 수정하는 것을 의미한다고 말했다.
하지만 그리고 나서 그는 주로 에러를 만들지 않는 법에 대해 이야기 했어야 했다.
디버깅은 단지 모든 경고와 함께 컴파일 하는 법과 일반적 언어의 잠재적 위험을 아는 것, 그리고 IDE의 모든 지원을 선택하여 사용하는 것을 넘어서는 스킬이다. 디버깅 스킬은 누구에게 물어볼 지를 아는 것보다 더 중요하다.
디버깅은 당신이 직면한 버그의 종류에 따라 직관적으로 접근할 수 있는데 도움이 되는 무기이다.
브라이언은 매우 중요한 두 가지를 제시했다. 변수 값을 출력하는 것과 함수 진입 확인을 위한 메시지를 콘솔에 출력하는 것.
이것은 내가 말하고자 하는 것이다.
이는 모든 프로그래머들이 사용할 수 있는 현실적, 실질적인 기술이다.
이것들에 대해서 더 읽어 보길 바란다.
자, 신입 개발자를 위한 나의 10가지 디버깅 실전 전략이다.
1. 브라이언이 얘기한 것처럼, printf(출력하라는 의미)
cout, print, echo 또는 당신의 언어에서 사용하는 출력 명령이 무엇이든 약간의 정보를 화면에 출력한다. 변수들의 값이 예상한 것과 맞는지 확인한다. 메시지를 함수에 집어 넣어라. 메시지를 집어 넣는 것은 간단하고 (보통은) 빠르게 할 수 있다. 만약 메시지를 추가한 것이 당신을 위해 동작하지 않고, 코드보다 출력이 더 많거나, 재 컴파일 하는 것이 분명히 성가시다면:
2. 디버거 사용법을 배워라 - 제대로
좋은 디버거 (GDB를 제안해도 될까요?) 사용을 배우는데 소요되는 시간은 당신의 프로그래밍 경력에 있어 10배, 아니 1000배의 시간을 줄여줄 것이다. 디버거를 사용하려 노력하는 것은 적어도 어떻게 모든 동작이 당신을 괴롭히는지 어렴풋이 알 수 있게 한다. 그것뿐만 아니라 5분 안에 잡아내기 힘든 문제를 디버거를 사용하여 보람이 있는 디버깅을 할 수 있다. 제대로 된 사용법을 배우기 위해 들인 시간이 얼마나 많은 가치가 있는지는 대해서는 더 이상 말이 필요 없다(부끄러운 줄 모르는 홍보 - GDB Walkthrough). (저자의 블로그 링크다).
3. 어떻게 버그를 재현하는지 정확하게 알아야 한다.
이것은 너무 뻔하게 들릴 것이다. 하지만 때때로 프로그래머들은 고객이나 테스트 부서에서 재현할 수 있는지 확인해보지 않고, 고객 또는 테스트 부서에서 불평하는 문제를 찾기 위해 코드를 살펴본다. 만약 대부분의 시간 동안 버그를 재현할 수 있다면, 항상 문제점의 원인을 찾을 수 있을 것이다. 다른 팁들: 같은 코드 또는 같은 빌드를 사용하고 같은 구성을 사용하라. 릴리즈 빌드인지 디버그 빌드인지 확인하라. 버그는 워크스테이션들과 사용 대상, 디버그와 릴리즈된 소프트웨어 사이에서 불쑥 나타나는 기질이 있다.
4. 핵심이 되는 파일과 시스템 로그 파일을 사용하라.
Crash 증거가 남게 프로그램을 짜라. 로그 파일들을 훑어보고, 핵심 덤프들을 살펴봐라. 시스템 로그를 읽고 오류들을 확인하라. 당신은 온갖 방법을 다 사용하는 탐정이다.
5. 가정을 세우고 그것을 증명하라.
무엇이 문제를 유발하는지에 대해서 알지 못해도 (그래픽의 작은 결함 - 기분 나쁜 - 로우 레벨 프로그래머들의 최악의 악몽), 아무리 이상하더라도, 추측해보고, 가설을 세우고, 기록해라. 코드 베이스에서 증거를 찾고, 당신의 가정을 증명하거나 틀렸음을 입증하라. 당신이 알고 있는 문제의 명백한 증거를 찾을 곳을 규정하고, 처리 방법에 대해서 정확히 생각하라. 만약 당신의 가정이 완벽하게 잘못되었다면, 증거를 찾는 과정에서 종종 보다 정확한 가정을 세우는데 도움이 되는 증거를 얻을 수 있다.
6. 분할정복 (Divide and conquer)
계층과 추상 계층으로 구성된 거대한 프로그램의 어디에서 문제가 처음 발생하는지 찾는 것은 매우 어려울 수 있다. 디버깅 툴을 사용하고 버그가 발생하기 전에 브레이크 포인트를 설정하라. 브레이크 포인트는 프로그램과 프로그램의 데이터의 스냅샷이다. 만약 모두 정상적으로 보이면, 알고 있는 정상 스냅샷과 버그가 발생하는 지점의 중간쯤(가장 근접한 추측)으로 브레이크 포인트를 설정한다. 버그를 찾을 때까지 반복하라. 이것(Binary Search)이 범인을 찾아내는 방법이다.
7. 단순화하라.
버그를 재현할 수 있는 가장 단순한 조건 설정을 찾아 버그를 재현할 수 있을 때까지 지엽적인 정보, 입력과 부가정보를 줄여라. 흔히 거대한 시스템에서 상당한 규모의 데이터와 커넥션들은 무슨 일이 일어나고 있는지 파악하는 것을 어렵게 한다. 줄이고 줄이고 줄여라. 디버깅을 위한 기본적인 설정, 정말 필요한 데이터, 적은 트래픽을 쉽게 찾을 수 있다. 하드웨어 제거의 부작용, 버그가 사라지는 지점의 데이터는 종종 문제의 원인을 파악하는데 도움을 준다.
8. 자동화하라
만약 오직 보름달이 떴을 때, 100미터 안에 까마귀 떼가 있을 때만 발생하는 간헐적인 버그라면, 디버거 아래에서 프로그램을 실행하도록 자동화할 만한 가치가 있다. 어떠한 기본적인 스크립팅 언어라도 당신에게 도움이 될 것이다. 당신이 에러를 확인할 수 있을 때까지 프로그램을 반복적으로 시작하도록 설정하라. Crash가 발생할 때까지 반복적으로 같은 입력으로 프로그램을 실행하도록 설정하라. 프로그램이 죽을 때까지 반복적으로 버튼을 누르도록 GUI를 설정하라. 힌트: 테스트 부서의 동료가 당신의 가장 큰 자산이 될 수 있다.
9. 빌드를 비교하라.
이것은 내가 좋아하는 일이 아니다. 하지만 릴리즈에 버그가 갑자기 나타났고 버그를 찾는 것이 어렵다면 전체 소스 트리를 비교하는 것은 어느 부분의 변경이 이슈를 발생시켰는지 파악하는데 도움이 될 수 있다. 주의: 시도했을 때 가끔씩만 가치가 있었다. 거대한 코드베이스에서 문제가 발생했을 때 모든 변경을 보는 것은 시간이 많이 걸리고 사기저하를 불러온다. 하지만 과거에 내가 업데이트들을 확인하고, 수정들을 분류했던 것은 문제를 찾아내는데 도움이 되었다.
10. 포기하지 말라
디버깅은 지루하고 시간이 오래 걸리는 작업 일 수 있다. 어떤 버그들은 악마의 작업이다(그럼에도 불구하고 찾았을 때 매우 단순하다). 인내하고 충분히 생각하라. 그 동안 다른 버그를 수정하거나 다른 일을 해라. 커피를 마시거나, 동료나 학우와 담소를 나누어라. 마음을 비우고 나서 다시 돌아와라. 여러 번 전날 저녁 파악하기 위해 씨름한 버그를 다음날 아침에 제일 먼저 발견했다. 마침내 문제의 근본 원인을 알아내고 해결하는 것은 굉장한 만족이다. 그리고 문제가 발생할 때마다, 문제는 당신을 더 나은 프로그래머로 만든다.
수색(버그의 원인을 찾는)을 즐겨라.
저자 : Faye Williams
역자 : 김준환
원문 : Debugging for beginners: a response
이 글은 브라이언 맥도날드가 포스팅한 신입 개발자를 위한 디버깅의 후속편이다. 나는 브라이언이 포스팅한 글을 탐독했다. 나는 모든 프로그래머(심지어 10년의 경력이 있어도)들을 가끔씩 성가시게 하는 찾기 힘든 문제들을 찾기 위해 항상 다른 접근법으로 바라보려 노력한다.
아무튼 나는 내가 조금 실망했다는 점을 인정한다. 보다시피, 브라이언은 모든 프로그래머들이 관심을 갖는 주제에 관하여 읽기 쉽고 훌륭한 글을 썼다. 하지만 나는 그의 글에서 어떻게 디버깅을 하는지(더 고급의, 이론적인 레벨보다는), 어떻게 오류를 줄일 수 있는지 대해서 더 적은 초점을 맞추고 있다는 점을 발견했다.
자 그럼, 당신은 오류를 줄이는 최고의 방법은 당신의 코드를 "디버그"하는 것이라 주장(내 남편이 그랬던 것처럼)할 수 있다. 분명히, 당신이 프로그래머로서 경험이 쌓일수록, 잠재적인 위험을 인식하고 방지하는 스킬은 늘어야 하고, 문제들을 해결하기 위해서는 적은 시간을 사용하고 더 많은 시간을 업무를 처리하는데 사용해야 한다.
좋다.
이론적으로, 이 주장에는 두 가지 결함이 있다.
1. 어느 시점에 당신의 소유가 아닌 다른 코드를 디버그 해야 한다.
2. 어느 시점에 당신이 소유한(또는 다른 누군가의) 코드에서 찾기 힘든 버그를 접해야 한다.
브라이언이 명시한 것처럼, 누구도 완벽하지 않으며, 당신의 코드도 완벽하지 않다. 심지어 숙련된 프로그래머가 된다는 것은 더 에러를 잘 찾고 잘 수정하는 것을 의미한다고 말했다.
하지만 그리고 나서 그는 주로 에러를 만들지 않는 법에 대해 이야기 했어야 했다.
디버깅은 단지 모든 경고와 함께 컴파일 하는 법과 일반적 언어의 잠재적 위험을 아는 것, 그리고 IDE의 모든 지원을 선택하여 사용하는 것을 넘어서는 스킬이다. 디버깅 스킬은 누구에게 물어볼 지를 아는 것보다 더 중요하다.
디버깅은 당신이 직면한 버그의 종류에 따라 직관적으로 접근할 수 있는데 도움이 되는 무기이다.
브라이언은 매우 중요한 두 가지를 제시했다. 변수 값을 출력하는 것과 함수 진입 확인을 위한 메시지를 콘솔에 출력하는 것.
이것은 내가 말하고자 하는 것이다.
이는 모든 프로그래머들이 사용할 수 있는 현실적, 실질적인 기술이다.
이것들에 대해서 더 읽어 보길 바란다.
자, 신입 개발자를 위한 나의 10가지 디버깅 실전 전략이다.
1. 브라이언이 얘기한 것처럼, printf(출력하라는 의미)
cout, print, echo 또는 당신의 언어에서 사용하는 출력 명령이 무엇이든 약간의 정보를 화면에 출력한다. 변수들의 값이 예상한 것과 맞는지 확인한다. 메시지를 함수에 집어 넣어라. 메시지를 집어 넣는 것은 간단하고 (보통은) 빠르게 할 수 있다. 만약 메시지를 추가한 것이 당신을 위해 동작하지 않고, 코드보다 출력이 더 많거나, 재 컴파일 하는 것이 분명히 성가시다면:
2. 디버거 사용법을 배워라 - 제대로
좋은 디버거 (GDB를 제안해도 될까요?) 사용을 배우는데 소요되는 시간은 당신의 프로그래밍 경력에 있어 10배, 아니 1000배의 시간을 줄여줄 것이다. 디버거를 사용하려 노력하는 것은 적어도 어떻게 모든 동작이 당신을 괴롭히는지 어렴풋이 알 수 있게 한다. 그것뿐만 아니라 5분 안에 잡아내기 힘든 문제를 디버거를 사용하여 보람이 있는 디버깅을 할 수 있다. 제대로 된 사용법을 배우기 위해 들인 시간이 얼마나 많은 가치가 있는지는 대해서는 더 이상 말이 필요 없다(부끄러운 줄 모르는 홍보 - GDB Walkthrough). (저자의 블로그 링크다).
3. 어떻게 버그를 재현하는지 정확하게 알아야 한다.
이것은 너무 뻔하게 들릴 것이다. 하지만 때때로 프로그래머들은 고객이나 테스트 부서에서 재현할 수 있는지 확인해보지 않고, 고객 또는 테스트 부서에서 불평하는 문제를 찾기 위해 코드를 살펴본다. 만약 대부분의 시간 동안 버그를 재현할 수 있다면, 항상 문제점의 원인을 찾을 수 있을 것이다. 다른 팁들: 같은 코드 또는 같은 빌드를 사용하고 같은 구성을 사용하라. 릴리즈 빌드인지 디버그 빌드인지 확인하라. 버그는 워크스테이션들과 사용 대상, 디버그와 릴리즈된 소프트웨어 사이에서 불쑥 나타나는 기질이 있다.
4. 핵심이 되는 파일과 시스템 로그 파일을 사용하라.
Crash 증거가 남게 프로그램을 짜라. 로그 파일들을 훑어보고, 핵심 덤프들을 살펴봐라. 시스템 로그를 읽고 오류들을 확인하라. 당신은 온갖 방법을 다 사용하는 탐정이다.
5. 가정을 세우고 그것을 증명하라.
무엇이 문제를 유발하는지에 대해서 알지 못해도 (그래픽의 작은 결함 - 기분 나쁜 - 로우 레벨 프로그래머들의 최악의 악몽), 아무리 이상하더라도, 추측해보고, 가설을 세우고, 기록해라. 코드 베이스에서 증거를 찾고, 당신의 가정을 증명하거나 틀렸음을 입증하라. 당신이 알고 있는 문제의 명백한 증거를 찾을 곳을 규정하고, 처리 방법에 대해서 정확히 생각하라. 만약 당신의 가정이 완벽하게 잘못되었다면, 증거를 찾는 과정에서 종종 보다 정확한 가정을 세우는데 도움이 되는 증거를 얻을 수 있다.
6. 분할정복 (Divide and conquer)
계층과 추상 계층으로 구성된 거대한 프로그램의 어디에서 문제가 처음 발생하는지 찾는 것은 매우 어려울 수 있다. 디버깅 툴을 사용하고 버그가 발생하기 전에 브레이크 포인트를 설정하라. 브레이크 포인트는 프로그램과 프로그램의 데이터의 스냅샷이다. 만약 모두 정상적으로 보이면, 알고 있는 정상 스냅샷과 버그가 발생하는 지점의 중간쯤(가장 근접한 추측)으로 브레이크 포인트를 설정한다. 버그를 찾을 때까지 반복하라. 이것(Binary Search)이 범인을 찾아내는 방법이다.
7. 단순화하라.
버그를 재현할 수 있는 가장 단순한 조건 설정을 찾아 버그를 재현할 수 있을 때까지 지엽적인 정보, 입력과 부가정보를 줄여라. 흔히 거대한 시스템에서 상당한 규모의 데이터와 커넥션들은 무슨 일이 일어나고 있는지 파악하는 것을 어렵게 한다. 줄이고 줄이고 줄여라. 디버깅을 위한 기본적인 설정, 정말 필요한 데이터, 적은 트래픽을 쉽게 찾을 수 있다. 하드웨어 제거의 부작용, 버그가 사라지는 지점의 데이터는 종종 문제의 원인을 파악하는데 도움을 준다.
8. 자동화하라
만약 오직 보름달이 떴을 때, 100미터 안에 까마귀 떼가 있을 때만 발생하는 간헐적인 버그라면, 디버거 아래에서 프로그램을 실행하도록 자동화할 만한 가치가 있다. 어떠한 기본적인 스크립팅 언어라도 당신에게 도움이 될 것이다. 당신이 에러를 확인할 수 있을 때까지 프로그램을 반복적으로 시작하도록 설정하라. Crash가 발생할 때까지 반복적으로 같은 입력으로 프로그램을 실행하도록 설정하라. 프로그램이 죽을 때까지 반복적으로 버튼을 누르도록 GUI를 설정하라. 힌트: 테스트 부서의 동료가 당신의 가장 큰 자산이 될 수 있다.
9. 빌드를 비교하라.
이것은 내가 좋아하는 일이 아니다. 하지만 릴리즈에 버그가 갑자기 나타났고 버그를 찾는 것이 어렵다면 전체 소스 트리를 비교하는 것은 어느 부분의 변경이 이슈를 발생시켰는지 파악하는데 도움이 될 수 있다. 주의: 시도했을 때 가끔씩만 가치가 있었다. 거대한 코드베이스에서 문제가 발생했을 때 모든 변경을 보는 것은 시간이 많이 걸리고 사기저하를 불러온다. 하지만 과거에 내가 업데이트들을 확인하고, 수정들을 분류했던 것은 문제를 찾아내는데 도움이 되었다.
10. 포기하지 말라
디버깅은 지루하고 시간이 오래 걸리는 작업 일 수 있다. 어떤 버그들은 악마의 작업이다(그럼에도 불구하고 찾았을 때 매우 단순하다). 인내하고 충분히 생각하라. 그 동안 다른 버그를 수정하거나 다른 일을 해라. 커피를 마시거나, 동료나 학우와 담소를 나누어라. 마음을 비우고 나서 다시 돌아와라. 여러 번 전날 저녁 파악하기 위해 씨름한 버그를 다음날 아침에 제일 먼저 발견했다. 마침내 문제의 근본 원인을 알아내고 해결하는 것은 굉장한 만족이다. 그리고 문제가 발생할 때마다, 문제는 당신을 더 나은 프로그래머로 만든다.
수색(버그의 원인을 찾는)을 즐겨라.
TAG :
이전 글 : this가 없는 자바스크립트
최신 콘텐츠