오랜만에 지하철에서 꺼내 들은 "실용주의 프로그래머".....
하드커버를 열고 주저 없이 처음으로 펼친 곳은
"디버깅"이다.

요즘 써드파티와 같이 일을하며, 문제해결을 위한
디버깅과 소통에 있어서 난감한적이 있다.

예전 , 팀장님은 디버깅을 하는데 있어서,
"내가 만든 곳에는 문제가 없다"라는 생각을
버리고 "내가 만든 곳에 문제가 있다"라고 했다.


실용주의에서는 "디버깅은 개발자에게 예민하고 감성적인 주제다" 라고
이야기를 한다.  
다른 개발자 혹은 테스터에게 어떤 문제에 대해서 리포팅을
받았을때 본인 스스로는 어떤 것을 느끼고? 어떤 행동을 하는가?

문제를 부정, 지목, 어설픈 변명 혹은 냉담(절대 내 문제일리 없어)등으로
대하지 않는가? 아니면, 그 상황을 인정하고, 최근 변경된 코드를 찬찬히 훓터보며
버그 재현을 통해 문제를 해결하려 하는가?

개발자라면 누구나 후자의 방법으로 문제 해결을 해나가야 할 것이다.
하지만 본인도 은근슬쩍 전자처럼 행동을 하는 경우가 많다.
우리가 가장 먼저 머리속에 각인 시켜야 할 것은 "문제는 발생했다" 라는 것이다.

자 실용주의 프로그래머는 남을 비난하기 보다는 문제를 고치는데,
집중하고 비록 내 문제가 아니었더라 하더라도, 상대방이 문제를 해결 해주면
칭찬의 한마디를 잊지 말자, 그렇지 않으면 당신의 퇴근시간이 더욱  늦어 질 것이다.


로니강은 이렇게 디버깅을 시작합니다..

1. 문제가 있다는 사실을 받아 들입니다.
문제에 대해서, 상세하게 기술을 합니다.
문제의 요점을 파악하기 위한것이죠.
추후에 동일한 문제가 발생했을 경우에 대비한 DB이기도 하고요.

2. 데이터(log)을 이용해라
"로그는 정직하다."
정상적인 경우와 비정상 적인 로그들을 모아서 저장 해 놔보세요.
txt 파일 몇백개를 유지 한다고 해서, 당신의 저장공간이 부족하거나 그렇지 않습니다.

버그가 발생했을 경우, 로그를 찬찬히 읽어보면,
어디서 무엇이 잘못 되었는지 확인 할 수 있습니다.
자 이제 코드를 살펴 보아요, 좀더 문제의 범위를 찾기 위해서,
몇라인의 로그를 더 심어야 할지도 모릅니다.

3. 분할 정복
알고리즘 책에서 이 말을 빼 놓지 않고 있죠?
문제를 해결하기 위해서도 꼭 필요한 개념입니다.

4. 소스 형상관리를 이용하는 것은 기본이겠죠?
SVN을 이용하여 원하는 시점으로 돌아가 보시고, 코드의 변경사항 들을
살펴 볼 수 있으니, 정말 좋은 환경입니다.
여러분의 실수는 Undo 할 수 있습니다.

자자! 실용주의 프로그래머는 자기 자신을 속이지 않습니다.

최근 같이 일하는 M사에 B군에게 실용주의 프로그래머라는
책을 선물 해주고 싶군요.


너무 성의 없는글이네요 :( 스르르르륵...

Wince5.0이나 WindowsMobile 같은 경우 MFC를 사용하지 않을경우
TRACE를 사용 할 수 없습니다.
따라서 아래처럼 구성해서 사용하시면 DebugMode에서만 동작하는
메시지를 만들 수 있습니다.

고운하루 되세요.