체계적인 디버깅
추측성 패치를 하지 마세요. 각 단계는 버그가 있을 수 있는 위치를 좁혀 나갑니다.
1. 재현
- 정확한 오류, 스택 추적, 로그, 입력 및 환경(버전, OS, 구성)을 확보하세요.
- 실패를 요청 시 재현 가능하게 만드세요. 이상적으로는 하나의 명령어나 하나의 테스트로 가능해야 합니다. 간헐적으로 발생하는 경우, 발생 가능성을 높이는 요소(부하, 타이밍, 순서, 특정 입력)를 찾으세요.
- 재현할 수 없다면 그 사실을 말하고 코드를 변경하기 전에 더 많은 정보를 수집하세요.
2. 격리
- 재현 조건을 축소하세요: 입력, 단계, 코드를 제거하여 더 이상 제거하면 버그가 사라지는 지점까지 줄이세요.
- 이전에는 작동했다면, 어떤 변경으로 인해 고장 났는지 찾으세요: 영향을 받는 파일에서
git log를 실행하거나git bisect run <test command>를 사용하세요. - 스택 추적은 프레임워크 코드가 아닌 당신의 코드의 상단부터 읽으세요.
3. 가설 수립 및 테스트
- 하나의 구체적인 가설을 적으세요: "캐시가 키가 로케일을 무시하기 때문에 오래된 항목을 반환한다."
- 가설을 증명하거나 반증할 검사를 설계하세요: 로그 라인, 어설션, 디버거 중단점, 단위 테스트. 실행하기 전에 결과를 예측하세요.
- 결과가 예상과 다르다면 코드에 대한 당신의 모델이 잘못된 것입니다. 다음 아이디어를 시도하기 전에 모델을 업데이트하세요.
- 한 번에 하나씩만 변경하세요. 도움이 되지 않은 실험은 되돌리세요.
4. 원인 수정
- 잘못된 값이 발견된 곳이 아니라 생성된 곳을 수정하세요. 동일한 실수가 다른 곳에도 있는지 확인하세요.
- 수정 전에는 실패하고 수정 후에는 통과하는 회귀 테스트를 추가하세요.
- 임시 로깅 및 디버그 코드를 제거하세요.
5. 보고
근본 원인을 한두 문장으로 설명하고, 수정 방법, 검증 방법, 그리고 아직 설명되지 않은 부분을 설명하세요.