에러 잡기 7단계
모하니?/Coding : 2009.07.21 16:09
참조: http://www.makinggoodsoftware.com/2009/06/14/7-steps-to-fix-an-error/
디버깅 왜 중요한가?
디버깅이란 소프트웨어 개발자가 버그를 고치는 행위를 말한다. 훌륭한 디버거가 되는 것은 훌륭한 개발자가 되기 위해 중요한 부분이다.
에러 잡기 7단계
스탭 1: 에러 식별하기
버그가 뭔지 알아야겠죠. "앗 버그다" 이러고 그냥.. 멍~~ 이러고 있으면 안 되겠죠. 무슨 버그인지 에러 메시지를 잘 읽어보거나, 에러를 다시 재현해 본다던가 말이죠.
스탭 2: 에러 찾기
정확히 에러가 어느지점에서 발생하는지 찾아야 합니다. 보통 이클립스 콘솔을 보면 메서드 호출 스택 중에서 프레임워크 패키지로 시작하는 것들 말고, 제가 작성한 패키지로 시작하는 부분을 보면 해당 클래스의 몇 번째 줄에서 예외가 발생했는지도 알 수 있죠. 대부분 그 지점에서 뭔가가 잘못됐을테죠. 아니면 ClassNotFound 같은 건 라이브러리 문제니까 특정 지점을 찾을 필요는 없곘네요. 쉽게 찾을 수 없는 경우 로깅, 디버깅, 작성했던 코드 빼기. 등을 사용해서 버그가 생긴 지점을 알 수 있겠습니다. 테스트를 작성해서 CI를 하는 이유 중 하나가 바로 이 에러가 발생한 지점을 찾을 때 생각해 볼 범위가 테스트에 반비례하기 때문인듯 합니다.
스탭 3: 에러 분석
해당 부분에서 무엇이 잘못됐는지 알아내는 겁니다. 확실하지 않다면 가설을 세워도 좋겠죠.
스탭 4: 분석 증명
이전 단계에서 분석을 했거나, 가설을 세웠다면 그것이 맞는지 테스트 코드를 이용해서 증명하는 단계입니다. 버그를 재현하는 테스트를 작성해서, 실패하는 테스트를 만듭니다. 테스트의 소중함을 알면서도 저는 보통 이 단계를 빼먹곤 하지요.
스탭 5: 연쇄 데미지 방지
분석 증명까지 끝났다면 바로 버그를 수정하는게 아니라, 수정하기 전 상태를 확인합니다. 이전 테스트들을 모두 실행해서 무사히 패스 하는지 확인하는 거죠. 이로써, 지금 수행할 버그 수정 작업이 이전 상태에 또 다른 버그를 만들지는 않는지 확인할 수 있습니다.
스탭 6: 버그 수정
수정하는 거죠~
스탭 7: 검증
모든 테스트를 실행하고 패스하는지 확인.
몇 가지 추천사항
버그와 그 수정 사항을 문서화 하라.
로깅을 하라.
툴을 사용하라.(이슈 트래커, 소스 관리, 디버깅 툴)
디버깅 왜 중요한가?
디버깅이란 소프트웨어 개발자가 버그를 고치는 행위를 말한다. 훌륭한 디버거가 되는 것은 훌륭한 개발자가 되기 위해 중요한 부분이다.
에러 잡기 7단계
스탭 1: 에러 식별하기
버그가 뭔지 알아야겠죠. "앗 버그다" 이러고 그냥.. 멍~~ 이러고 있으면 안 되겠죠. 무슨 버그인지 에러 메시지를 잘 읽어보거나, 에러를 다시 재현해 본다던가 말이죠.
스탭 2: 에러 찾기
정확히 에러가 어느지점에서 발생하는지 찾아야 합니다. 보통 이클립스 콘솔을 보면 메서드 호출 스택 중에서 프레임워크 패키지로 시작하는 것들 말고, 제가 작성한 패키지로 시작하는 부분을 보면 해당 클래스의 몇 번째 줄에서 예외가 발생했는지도 알 수 있죠. 대부분 그 지점에서 뭔가가 잘못됐을테죠. 아니면 ClassNotFound 같은 건 라이브러리 문제니까 특정 지점을 찾을 필요는 없곘네요. 쉽게 찾을 수 없는 경우 로깅, 디버깅, 작성했던 코드 빼기. 등을 사용해서 버그가 생긴 지점을 알 수 있겠습니다. 테스트를 작성해서 CI를 하는 이유 중 하나가 바로 이 에러가 발생한 지점을 찾을 때 생각해 볼 범위가 테스트에 반비례하기 때문인듯 합니다.
스탭 3: 에러 분석
해당 부분에서 무엇이 잘못됐는지 알아내는 겁니다. 확실하지 않다면 가설을 세워도 좋겠죠.
스탭 4: 분석 증명
이전 단계에서 분석을 했거나, 가설을 세웠다면 그것이 맞는지 테스트 코드를 이용해서 증명하는 단계입니다. 버그를 재현하는 테스트를 작성해서, 실패하는 테스트를 만듭니다. 테스트의 소중함을 알면서도 저는 보통 이 단계를 빼먹곤 하지요.
스탭 5: 연쇄 데미지 방지
분석 증명까지 끝났다면 바로 버그를 수정하는게 아니라, 수정하기 전 상태를 확인합니다. 이전 테스트들을 모두 실행해서 무사히 패스 하는지 확인하는 거죠. 이로써, 지금 수행할 버그 수정 작업이 이전 상태에 또 다른 버그를 만들지는 않는지 확인할 수 있습니다.
스탭 6: 버그 수정
수정하는 거죠~
스탭 7: 검증
모든 테스트를 실행하고 패스하는지 확인.
몇 가지 추천사항
버그와 그 수정 사항을 문서화 하라.
로깅을 하라.
툴을 사용하라.(이슈 트래커, 소스 관리, 디버깅 툴)
'모하니? > Coding' 카테고리의 다른 글
| [하이버네이트] OneToMany에 FetchType.EAGER 사용시 어떤 일이 생길까? (0) | 2009.07.28 |
|---|---|
| [Mockito] mock 객체 쉽게 만들기 (2) | 2009.07.27 |
| [하이버네이트]롹킹과 성능 사이에 서다. (1) | 2009.07.23 |
| JUnit 4.7 새 기능 @Rule (2) | 2009.07.22 |
| 윈도우에서 모나코 폰트 이쁘게 쓰기 (6) | 2009.07.22 |
| 에러 잡기 7단계 (0) | 2009.07.21 |
| 내일은 꼭 Monaco 폰트 설치해야지 (8) | 2009.07.20 |
| 스프링 시큐리티 2.X -> 스프링 시큐리티 3.X (2) | 2009.07.17 |
| 모르겠네.. @_@ (2) | 2009.07.15 |
| 스프링 JSON view와 jQuery 이용하여 자동완성 기능 만들기 4 (0) | 2009.07.14 |
| 스프링 JSON view와 jQuery 이용하여 자동완성 기능 만들기 3 (0) | 2009.07.14 |
TAG 버그 잡기 7단계
