리누즈 토발즈(Linus Torvalz)가 디버깅에 대해 쓴 쓰레드중 일부이다.[1]
...
I'm afraid that I've seen too many people fix bugs
by looking at debugger output, and that almost
inevitably leads to fixing the symptoms rather than
the underlying problems.
...
"Use the Source, Luke, use the Source. Be one with
the code.". Think of Luke Skywalker discarding the
automatic firing system when closing on the deathstar,
and firing the proton torpedo (or whatever) manually.
_Then_ do you have the right mindset for fixing kernel
bugs.
...
...
그동안 많은 사람들이 디버거 출력을 보고 버그를 고쳐, 실제 문제가 아닌 필연적으로 단순히 문제의 조짐만 해결하게 되어 온 것이 걱정스럽다.
...
"소스를 사용하라, 루크, 소스를... 코드가 함께 하길"[2] 죽음의 별이 폭발할때, 루크 스카이워크가 자동 발사 장치를 버리고 양성자 어뢰를 직접 발사하는 것을 생각하라. _그러면_ 커널 버그를 고칠 올바른 마음가짐(정신)을 가지게 될 것이다.
...
간단하게, 자동 장치인 디버거를 버리고, 머리속으로 코드의 핵심을 보라는 말이다. 실제로, 코드 자체의 논리적 문제보다는 디버거를 통해서 오류를 잡는 것이 나를 포함한 많은 사람들에게 너무 익숙해져있고 당연시 받아들여진다. 실제로 초보시절에는 컴파일을 했을때 문법 오류가 나지 않으면 불안 증세까지 생기곤 했다.
이것이 조금은 나아질 뿐, 결과적으로 나중에도 디버깅에서 나오는 오류에 의존하는 경우가 대부분이라면 문제가 될 것이다. 예를 들어 메모리 누수 같은 경우도, 논리적으로 따져보고 누수를 없앤 후, 누수 체킹으로 누수가 없는 것을 확실히 하는 것이 아닌, 일단 대충 짜서 돌려보고, 그 다음 누수의 원인 체킹(VC++에서 기본적으로 제공되는 디버거만으로도 누수의 원인을 찾을 수 있다[3])
결과적으로, 가장 훌륭한 디버깅 툴인 사람의 머리는, 당장은 가장 느린 툴이 될 수 있을지 모르겠다. 하지만 점차 버전업(?)을 해가는데에 가장 큰 의미가 있는 것이고, 장기적으로 봤을때는 가장 훌륭한 툴임에는 틀림이 없다.
...
I'm afraid that I've seen too many people fix bugs
by looking at debugger output, and that almost
inevitably leads to fixing the symptoms rather than
the underlying problems.
...
"Use the Source, Luke, use the Source. Be one with
the code.". Think of Luke Skywalker discarding the
automatic firing system when closing on the deathstar,
and firing the proton torpedo (or whatever) manually.
_Then_ do you have the right mindset for fixing kernel
bugs.
...
...
그동안 많은 사람들이 디버거 출력을 보고 버그를 고쳐, 실제 문제가 아닌 필연적으로 단순히 문제의 조짐만 해결하게 되어 온 것이 걱정스럽다.
...
"소스를 사용하라, 루크, 소스를... 코드가 함께 하길"[2] 죽음의 별이 폭발할때, 루크 스카이워크가 자동 발사 장치를 버리고 양성자 어뢰를 직접 발사하는 것을 생각하라. _그러면_ 커널 버그를 고칠 올바른 마음가짐(정신)을 가지게 될 것이다.
...
간단하게, 자동 장치인 디버거를 버리고, 머리속으로 코드의 핵심을 보라는 말이다. 실제로, 코드 자체의 논리적 문제보다는 디버거를 통해서 오류를 잡는 것이 나를 포함한 많은 사람들에게 너무 익숙해져있고 당연시 받아들여진다. 실제로 초보시절에는 컴파일을 했을때 문법 오류가 나지 않으면 불안 증세까지 생기곤 했다.
이것이 조금은 나아질 뿐, 결과적으로 나중에도 디버깅에서 나오는 오류에 의존하는 경우가 대부분이라면 문제가 될 것이다. 예를 들어 메모리 누수 같은 경우도, 논리적으로 따져보고 누수를 없앤 후, 누수 체킹으로 누수가 없는 것을 확실히 하는 것이 아닌, 일단 대충 짜서 돌려보고, 그 다음 누수의 원인 체킹(VC++에서 기본적으로 제공되는 디버거만으로도 누수의 원인을 찾을 수 있다[3])
결과적으로, 가장 훌륭한 디버깅 툴인 사람의 머리는, 당장은 가장 느린 툴이 될 수 있을지 모르겠다. 하지만 점차 버전업(?)을 해가는데에 가장 큰 의미가 있는 것이고, 장기적으로 봤을때는 가장 훌륭한 툴임에는 틀림이 없다.
- 일단 이 내용은 이곳에서 퍼왔다. http://www.kernel.org/pub/linux/kernel/people/andrea/ikd/README 하지만 이글은 (내가 알기로는) 원래 메일로 주고 받았거나, 커뮤니티의 쓰레드에서 발췌한 것으로 알고 있다. [본문으로]
- 스타워즈를 본 사람은 다 알 수 있을듯.. 하지만, Be one with the code 는 내가 해석한것이 맞는지 모르겠다. 스타워즈에서 원래 나오는 말은 "May the force be with you 이다." 그것을 정확히 Be one with the code 로 빗댄것인지는 확실하지 않다. [본문으로]
- MS에서 친절하게 방법을 설명한다. http://support.microsoft.com/kb/601929/ko 어이 없던 것은, 이글이 다른 블로그에 출처도 없이 퍼날려져 있던 것이고, 더 어이 없던 것은 이 글을 쓴곳(데브피아)에서 자기도 MS에서 글을 얻어왔으면서도 포럼에는 마치 자기가 쓰는 강좌 인양 써놨다. (출처를 썼는지는 확인이 안됐지만, 애당초 자신의 강좌인양 번호까지 붙여가면서 쓰는것은 말이 안된다.) [본문으로]







462729
389
460







댓글을 달아 주세요