[실용주의 프로그래머] Topic 20 디버깅

Topic 20 디버깅

기억할 내용

- 디버깅의 심리 : 단지 문제 풀이일 뿐이라는 사실을 받아들이고, 그런 마음으로 공략하라.

- 다른 사람의 버그를 발견 후, 그 버그를 만들어 낸 부정한 범죄자를 비난하는 데에 시간과 노력을 쏟지말고 ... 기술의 전당에서는 남을 비난하기보다 문제를 고치는 데에 집중해야 한다.

- Tip29 비난 대신 문제를 해결하라.

- 버그가 여러분의 잘못인지 다른 사람의 잘못인지는 중요치 않다. 어쨌거나 그 버그를 해결해야 하는 사람은 여러분이다.

- 디버깅 사고 방식 : 가장 속이기 쉬운 사람은 자기 자신이다. - 애드워드 불워 -리턴

- 버그를 목격하거나 버그 신고를 보는 순간의 첫 반응이 '그건 불가능해'라면 여러분은 두말할 필요 없이 틀렸다.'정말 그럴 리가 없는데'로 시작하는 생각의 흐름에 신경 세포 하나도 낭비하지 말라.

- 특정한 증상만 고치지 말고 항상 문제의 근본 원이을 찾으려고 노력 하라

- 실마리 찾기 : 우연에 의해 오도되기 쉽다. 우리는 우연한 사건을 디버깅하느라 시간을 낭비할 여유가 없다. 일단 정확하게 관찰해야 한다. 

디버깅 전략 

- 버그 재현하기 : 재현할 수 없다면 어떻게 그 버그를 고쳤다는 것을 확인할 수 있겠는가?

- Tip31 고치기 전에 실패하는 테스트부터

- Tip32 그놈의 오류메시지 좀 읽어라

- 이상한 결과 : 실패하는 테스트를 이용하여 문제를 재현하라 

- 메모를 하면 도움이 될 때가 많다. 추적을 시작할 때 우리가 어디에 있었는데 메모를 남겨 두지 않았다면 원래 자리로 돌아오느라 시간을 많이 소모했을 것이다.

- 로깅과 트레이싱 : 트레이싱 구문은 '여기까지 도달'이나 'x값 = 2'와 같이 화면 혹은 파일에 출력하는 작은 진단용 메시지를 일컫는다.

- 트레이싱은 여러 프로세스가 동시에 작동하는 경우, 실시간 시스템, 이벤트 기반 애플리케이션 등, 시간 자체가 중요한 요소가 되는 시스템에서 이루 말할 수 없이 소중하다.

- 고무오리 : 문제의 원인을 찾는 방법에는 그냥 누군가에게 설명하는 방법이 있다.

- 문제를 설명하게 되면 혼자 코드를 살펴볼 때는 당연히 여기고 지나갈 것을 명시적으로 이야기해야 한다.

- 소거법 : 사람들이 작성한 애플리케이션 코드, 외부 제품(데이터베이스나 네티워크, 웹 프레임워크, 특화된 통신 방식, 알고리즘 등) 플랫폼 환경(운영체제, 시스템 라이브러리, 컴파일러)이 뒤섞여 있을 것이다. 하지만 처음부터 그런 생각을 하지는 말라

- 발굽 모양을 보면 말을 떠올려야지 얼룩말부터 떠올리지 말라

- 가정하지 말라, 증명하라

 

느낀 점

 이번 주제는 내용도 많고, 개발할 때 중요하게 생각했던 것들이라 생각된다. 공감이 되는 부분이 꽤나 많았다.  발하다 보면 버그가 발생하는데 이 버그가 누가 만들어 냈는지 궁금할 때가 많은데, 그럴 시간에 문제를 해결하려고 노력하는 것이 맞다. 그리고 다른 사람의 의해 나의 작업물에 버그가 보고 되면 그 부분에서는 그럴 리가 없는 데를 얘기한 내가 부끄러웠다.(그럴 리가 없는데, 발생했잖아). 

버그를 추적할 때 메모장을 사용하기, 누군가에게 설명하기, 로깅과 트레이싱(은 몰랐던 용어라 찾아봄)등 디버깅에 필요한 방법들을 제시해주고 있어 실제로 버그 발생 시 적용해 볼만 것들이 많았다.