Q&A와 스터디
![[레벨:5]](http://old.lameproof.com/modules/point/icons/default/5.gif "포인트:2366point (11%), 레벨:5/30"){kind=icon}
못짱게임 코디는 견학이라고 질문도 못쓰게 해서 여기다가 남겨봅니다.
현업에서 프로그래밍 하시는분들은 주로 어떤 방식의 디버깅을 하시나요?
1. try & catch, assert, if 총 동원해서 디버깅 한다.
2. try catch 등을 쓰지 않고 그냥 비주얼 스튜디오의 디버거에 모든것을 맡긴다.
3. 또 다른 방법이 있다.
현업에서 프로그래밍 하시는분들은 주로 어떤 방식의 디버깅을 하시나요?
1. try & catch, assert, if 총 동원해서 디버깅 한다.
2. try catch 등을 쓰지 않고 그냥 비주얼 스튜디오의 디버거에 모든것을 맡긴다.
3. 또 다른 방법이 있다.
2009.12.29 14:40:46 (*.131.190.240)
![[레벨:6]](http://old.lameproof.com/modules/point/icons/default/6.gif "포인트:4254point (86%), 레벨:6/30"){kind=icon}
bard 아... 그리고 덤으로, poll 이라고 말씀 하셨지만 선택사항으로 둔 1/2/3 을 나눈 기준이 올바르지 않습니다. 따라서 해당 설문은 별 의미가 없을듯 합니다.
2009.12.29 15:16:08 (*.39.123.153)
![[레벨:7]](http://old.lameproof.com/modules/point/icons/default/7.gif "포인트:5507point (81%), 레벨:7/30"){kind=icon}
1ststory일반적으로 디버깅은 중단점을 걸어야죠.
중단점의 기능을 잘 찾아보면 매우 다양한 기능이 숨어있습니다. 조건을 명시할수도 있고 호출된 횟수나 다른 매크로 옵션을 실행시키는 기능도 있습니다.
그렇다고 해도 디버그의 방식은 정해져있는건 아닙니다.
개인적으로 생각하는 디버그의 가장 공통된 명제는 뭘쓰든 빨리 원인을 찾으면 장땡이라는 겁니다.
그렇기 때문에 개인의 디버깅을 하는 방식의 취향차가 존재합니다.
몇가지 외적인 방식에 대한 내용을 예로 들어보자면
필요에 따라 데이터의 흐름이 엇갈리기 시작한 원인을 찾기 위해 printf 문을 마구 심어서 메모장으로 printf 된 내용을 통채로 옮겨서 원하는 데이터를 검색한다거나
SVN같은 버전관리 툴을 이용해서 문제가 발생되기 시작한 시점으로 되돌려 본다음에 그때의 커밋 로그를 뒤져서 원인을 찾는 방식도 존재하죠.
하지만 위의 방식은 일반적인 디버그를 하는 방법론이고, 버그를 찾는 가장 좋은 방법은 프로그램이 죽었을때 죽은 원인을 로그로 남기는 것들이 필요합니다.
스택덤프를 남기거나, assert 문에 걸리면 어떠한 이유에서 걸렸는지 원인을 명확히 로그에 남기는 것이죠. 메모리 오버런 같은 귀찮은 상황만 제외하고는 대부분의 버그는 여기서 찾아내거나 예외 처리를 할수 있게 됩니다.
※ 2009-12-29 15:16:44 에 "1ststory(rockhwa)" 에 의해 수정됨
중단점의 기능을 잘 찾아보면 매우 다양한 기능이 숨어있습니다. 조건을 명시할수도 있고 호출된 횟수나 다른 매크로 옵션을 실행시키는 기능도 있습니다.
그렇다고 해도 디버그의 방식은 정해져있는건 아닙니다.
개인적으로 생각하는 디버그의 가장 공통된 명제는 뭘쓰든 빨리 원인을 찾으면 장땡이라는 겁니다.
그렇기 때문에 개인의 디버깅을 하는 방식의 취향차가 존재합니다.
몇가지 외적인 방식에 대한 내용을 예로 들어보자면
필요에 따라 데이터의 흐름이 엇갈리기 시작한 원인을 찾기 위해 printf 문을 마구 심어서 메모장으로 printf 된 내용을 통채로 옮겨서 원하는 데이터를 검색한다거나
SVN같은 버전관리 툴을 이용해서 문제가 발생되기 시작한 시점으로 되돌려 본다음에 그때의 커밋 로그를 뒤져서 원인을 찾는 방식도 존재하죠.
하지만 위의 방식은 일반적인 디버그를 하는 방법론이고, 버그를 찾는 가장 좋은 방법은 프로그램이 죽었을때 죽은 원인을 로그로 남기는 것들이 필요합니다.
스택덤프를 남기거나, assert 문에 걸리면 어떠한 이유에서 걸렸는지 원인을 명확히 로그에 남기는 것이죠. 메모리 오버런 같은 귀찮은 상황만 제외하고는 대부분의 버그는 여기서 찾아내거나 예외 처리를 할수 있게 됩니다.
※ 2009-12-29 15:16:44 에 "1ststory(rockhwa)" 에 의해 수정됨
2009.12.29 18:33:50 (*.74.149.140)
emoticon_15 테디베어 디버깅 방법을 사용하고 있습죠. 다만 진짜 테디베어한테 설명하는게 아니라 노트에다가 루틴을 따라가며 그려봅니다.
이건 뭐 특별한 경우고요, 보통은 화면출력, 콘솔로그, 파일로그, 일단 문제되는부분 주석...등으로 해봅니다.
이건 뭐 특별한 경우고요, 보통은 화면출력, 콘솔로그, 파일로그, 일단 문제되는부분 주석...등으로 해봅니다.
2009.12.30 02:15:00 (*.15.214.228)
![[레벨:2]](http://old.lameproof.com/modules/point/icons/default/2.gif "포인트:676point (70%), 레벨:2/30"){kind=icon}
imays 현업이건 아니건 진리의 디버깅 원칙과 요령은 있습니다. debugging applications for microsoft windows가 짱.
현업에서는 배포된 프로그램이 뻑나면 조속히 해결해야 하는 상황이 있다보니 덤프 수집기 같은 것들이 동원되기도 하죠.
현업에서는 배포된 프로그램이 뻑나면 조속히 해결해야 하는 상황이 있다보니 덤프 수집기 같은 것들이 동원되기도 하죠.
2010.01.04 17:38:26 (*.162.234.53)
![[레벨:3]](http://old.lameproof.com/modules/point/icons/default/3.gif "포인트:1095point (45%), 레벨:3/30"){kind=icon}
니우 디버깅시 예외처리라는 말이 와닫지 않는데, 바드님이 말씀하셨듯이 try~catch, assert는 디버그에 사용되는게 아니라 예외처리용입니다.
전 디버깅엔 덤프를 사용합니다(__).
테스트 중에 나오면 원격 디버깅으로 연결하기도 하지만...
예외처리로 빠진 사항에서 예외에 대한 로그를 남길수 있다면 남기는 것이 제일 좋습니다.
전 디버깅엔 덤프를 사용합니다(__).
테스트 중에 나오면 원격 디버깅으로 연결하기도 하지만...
예외처리로 빠진 사항에서 예외에 대한 로그를 남길수 있다면 남기는 것이 제일 좋습니다.
2013.05.19 11:41:30 (*.153.235.115)
bestbasci01@yahoo.com
try/catch 는 버그를 잡기위해 쓰는게 아닙니다.
assert 역시 디버깅을 위한 방법은 아닙니다.
if 야 말할 것 없이, 디버깅용은 아니겠지요.
다음으로
try-catch 구문은 예외를 처리합니다. 예외란 것은 버그와 명백히 구분됩니다.
파일을 읽으려 하였으나 파일이 없다 라던가. 서버에 접속을 하려 했으나 서버가 죽었다와 같은, 코딩하는 시점에서 결정지을 수 없는 여러가지 환경적인 요인으로 발생하는 예외상황을 예외라고 부르며, 이런 상황에서 프로그램이 폭주(?)하는것을 막기 위해 사용하는 것이 try-catch 구문입니다.
좀 더 안전한, 그러니까 개발자가 예상하지 못한 방향으로 프로그램이 작동하지 않도록 하기 위해 두는 안전장치라고 보셔야겠죠. 버그는 개발자가 예상하지 못한 방향으로 프로그램이 작동하는 것을 버그라고 부릅니다. try-catch 로 처리해 놓은 부분은 개발자가 예상할 수 있는 부분입니다. 따라서 디버깅과는 관련이 없는 주제라고 보셔야 겠죠.
assert 는 try-catch 와는 다소 다르지만, 디버깅용으로 개발 된 것은 아닙니다. 디버깅을 하려면 TRACE를 찍던가, conditional-breakpoint를 걸겠죠. assert 는 일종의 요구사항입니다. 예를들어 화면에 스프라이트를 그리는 함수가 있다고 치고, 이 함수에는 당연히 스프라이트 객체의 포인터가 넘어와야 할 것입니다. (물론 참조를 넘겨서 null-pointer 를 미연에 방지하는게 낫겠지만 예로써) 그런데 NULL 포인터가 넘어오면 어떻게 되겠습니까? 프로그램이 오동작을 하겠죠. 이런 경우를 미연에 체크하여 개발과정에서 발생할 수 있는 모호한 상황을 제거하기 위해 assert 를 사용합니다.
일종의 최소한의 요구조건을 정의하는 것이라고 봐야겠죠. 이 함수를 쓰기 위해 a 파라미터는 NULL이 아니어야 한다 던가, 좌표는 0보다 커야 한다던가 등등 여러가지 제약사항을 정의하고, 그 함수를 잘못 사용했을 경우 즉각 피드백을 받을 수 있도록 해 놓은 안전장치입니다. 이 역시 버그를 방지하기 위해 쓰는 테크닉이지 디버깅 용도가 주 용도는 아닙니다.
디버깅은 버그를 잡는 일련의 과정을 말하는 것이므로, 복합적인 기술을 사용하게 되겠지요. 일단 try-catch/assert 는 디버깅용으로 사용하는게 아니다 라는 말씀을 해 드리고 싶었습니다. ^^;