버그 진단
강력한 이론을 세우기 전에 빠르고 구체적인 통과/실패 신호를 구축하세요. 명령, 출력, 추적, 저장된 아티팩트에서 비밀 정보를 삭제하세요.
루프
- 재현. 사용자의 정확한 증상에 도달하고 이 버그에서 실패할 수 있는 하나의 명령을 작성하세요. 좁은 재현기가 없는 경우 references/feedback-loop.md를 읽으세요.
- 최소화. 입력, 단계, 호출자, 구성을 하나씩 제거하세요. 실패에 필요한 것만 남기세요.
- 가설 세우기. 3~5개의 순위가 매겨진 반증 가능한 원인을 작성하세요. 각 원인에 대해 이를 확인하거나 기각할 관찰 결과를 명명하세요.
- 프로빙. 한 번에 하나의 변수를 변경하세요. 디버거나 경계에 초점을 맞춘 계측을 선호하세요. 임시 로그에는 고유한
[DEBUG-...]접두사를 태그하세요. - 수정 고정. 가장 작은 실제 재현을 올바른 공개 경계에서 실패하는 회귀 테스트로 전환하세요. 가장 작은 수정을 적용하세요. 테스트와 원래 재현을 다시 실행하세요.
- 정리. 임시 계측과 테스트 하네스를 제거하세요. 원인, 증거, 수정, 그리고 남은 적용 범위 격차를 보고하세요.
규칙
- 두 번의 수정 시도가 실패한 후에는 멈추세요. 다른 패치를 시도하기 전에 가설이나 설계를 재확인하세요. 추측을 쌓지 마세요.
- 성능 회귀의 경우, 코드를 변경하기 전에 기준선을 측정하고 프로파일링하거나 이분 탐색을 수행하세요. 로그만으로는 성능 진단이 아닙니다.
- 올바른 테스트 경계가 없으면 그렇게 말하세요. 수정 후
$codebase-design을 사용하여 누락된 경계가 구조적 작업을 필요로 하는지 판단하세요. - 원래 증상이 사라지고 회귀 검사가 통과된 경우에만 성공을 주장하세요.