참조: http://www.makinggoodsoftware.com/2009/06/14/7-steps-to-fix-an-error/

디버깅 왜 중요한가?

디버깅이란 소프트웨어 개발자가 버그를 고치는 행위를 말한다. 훌륭한 디버거가 되는 것은 훌륭한 개발자가 되기 위해 중요한 부분이다.

에러 잡기 7단계

스탭 1: 에러 식별하기

버그가 뭔지 알아야겠죠. "앗 버그다" 이러고 그냥.. 멍~~ 이러고 있으면 안 되겠죠. 무슨 버그인지 에러 메시지를 잘 읽어보거나, 에러를 다시 재현해 본다던가 말이죠.

스탭 2: 에러 찾기

정확히 에러가 어느지점에서 발생하는지 찾아야 합니다. 보통 이클립스 콘솔을 보면 메서드 호출 스택 중에서 프레임워크 패키지로 시작하는 것들 말고, 제가 작성한 패키지로 시작하는 부분을 보면 해당 클래스의 몇 번째 줄에서 예외가 발생했는지도 알 수 있죠. 대부분 그 지점에서 뭔가가 잘못됐을테죠. 아니면 ClassNotFound 같은 건 라이브러리 문제니까 특정 지점을 찾을 필요는 없곘네요. 쉽게 찾을 수 없는 경우 로깅, 디버깅, 작성했던 코드 빼기. 등을 사용해서 버그가 생긴 지점을 알 수 있겠습니다. 테스트를 작성해서 CI를 하는 이유 중 하나가 바로 이 에러가 발생한 지점을 찾을 때 생각해 볼 범위가 테스트에 반비례하기 때문인듯 합니다.

스탭 3: 에러 분석

해당 부분에서 무엇이 잘못됐는지 알아내는 겁니다. 확실하지 않다면 가설을 세워도 좋겠죠.

스탭 4: 분석 증명

이전 단계에서 분석을 했거나, 가설을 세웠다면 그것이 맞는지 테스트 코드를 이용해서 증명하는 단계입니다. 버그를 재현하는 테스트를 작성해서, 실패하는 테스트를 만듭니다. 테스트의 소중함을 알면서도 저는 보통 이 단계를 빼먹곤 하지요.

스탭 5: 연쇄 데미지 방지

분석 증명까지 끝났다면 바로 버그를 수정하는게 아니라, 수정하기 전 상태를 확인합니다. 이전 테스트들을 모두 실행해서 무사히 패스 하는지 확인하는 거죠. 이로써, 지금 수행할 버그 수정 작업이 이전 상태에 또 다른 버그를 만들지는 않는지 확인할 수 있습니다.

스탭 6: 버그 수정

수정하는 거죠~

스탭 7: 검증

모든 테스트를 실행하고 패스하는지 확인.

몇 가지 추천사항

버그와 그 수정 사항을 문서화 하라.
로깅을 하라.
툴을 사용하라.(이슈 트래커, 소스 관리, 디버깅 툴)