구현은 어느정도 시간 예측이 가능하지만 디버깅은 시간 예측이 어렵다.

일정을 지키지 못하는 주요 이유가 된다.

디버깅을 잘하는 가장 좋은 방법은 디버깅을 하지 않아도 되는 환경을 구축하는 것.

문제가 발생한 순간에 디버깅을 하지 않고도 원인을 알 수 있게 하자.

잘 구축해두면 심지어 비프로그래머 직군에서도 원인을 파악할 수 있으므로 프로그래머의 일을 덜 수 있다.

로그는 최고의 방법 중 하나. 로그만 잘 출력해두어도 대부분의 원인 파악이 가능.

3D 게임의 경우 기즈모나 그래프와 같이 비주얼 툴을 활용하면 좋다.

자주 디버깅하게 되는 케이스를 하나 정해서 어떻게 하면 디버깅 없이 원인 파악이 될지 고민해보자. 로그나 기즈모 외에도 다양한 아이디어가 가능하다.

버그 제보를 받으면 “그거 내가 다 테스트 했는데, 왜 버그가 있다고 그러지?” 라는 마음이 들 때가 있다. 이런 마음으로 디버깅을 하면 코드의 정상적인 경로에 집중해서 보게 되고, ‘버그 여기 있어요’라 고 소리치는 눈 앞의 코드나 콜스택을 보고도 지나치게 된다. ⇒ 확증 편향 (Confirmation Bias)

“내가 테스트 한 후에 환경이 바뀌었나?”라던가 “내가 예상 못한 테스트 케이스가 있었나?”라는 마음으로 디버깅을 하면 보다 넓은 시야를 가질 수 있게 된다.