디버거가 항상 완벽한 솔루션은 아니며 항상 디버깅을위한 솔루션이되어서는 안된다는 점을 덧붙이고 싶습니다. 다음은 디버거가 작동하지 않을 수있는 몇 가지 경우입니다.
- 실패한 프로그램의 부분은 정말 크며 (아마도 모듈화 불량일까요?) 코드를 단계별로 시작할 위치를 정확히 알 수 없습니다. 모든 단계를 진행하는 데 너무 많은 시간이 소요될 수 있습니다.
- 프로그램은 많은 콜백 및 기타 비선형 흐름 제어 방법을 사용하므로 단계별로 디버거를 혼란스럽게 만듭니다.
- 프로그램은 다중 스레드입니다. 또는 더 나쁜 것은 경쟁 조건으로 인해 문제가 발생한다는 것입니다.
- 버그가있는 코드는 버그가 발생하기 전에 여러 번 실행됩니다. 이것은 특히 메인 루프에서 문제가 될 수 있으며, 물리 엔진에서는 문제가 수치적일 수있는 경우에 더욱 심각 할 수 있습니다. 이 경우 중단 점을 설정하는 경우에도 버그가 나타나지 않고 여러 번 누르게됩니다.
- 프로그램은 실시간으로 실행되어야합니다. 이것은 네트워크에 연결되는 프로그램에 대한 큰 문제입니다. 네트워크 코드에 중단 점을 설정하면 다른 쪽 끝은 단계를 통과 할 때까지 기다리지 않고 단순히 시간이 초과됩니다. 시스템 시계에 의존하는 프로그램 (예 : 프레임 스킵이있는 게임)도 그다지 좋지 않습니다.
- 프로그램은 파일에 쓰기 또는 이메일 보내기와 같은 일종의 파괴적인 작업을 수행하고이를 통해 실행해야하는 횟수를 제한하려고합니다.
- 함수 X에 잘못된 값이 도착하여 버그가 발생했다고 말할 수 있지만 이러한 값의 출처를 알 수 없습니다. 프로그램을 반복해서 실행하고 중단 점을 더 멀리 뒤로 설정하는 것은 매우 번거로울 수 있습니다. 특히 프로그램 전체에서 함수 X가 여러 곳에서 호출되는 경우.
이러한 모든 경우에 프로그램을 갑자기 중지하면 최종 결과가 달라 지거나 버그가 발생한 한 줄을 수동으로 검색하는 것이 너무 번거 롭습니다. 이는 버그가 잘못된 동작이든 충돌이든 똑같이 발생할 수 있습니다. 예를 들어, 메모리 손상으로 인해 크래시가 발생하면 크래시가 발생했을 때 메모리 손상이 처음 발생한 위치에서 너무 멀리 떨어져 유용한 정보가 남아 있지 않습니다.
그렇다면 대안은 무엇입니까?
가장 간단한 것은 단순히 로깅과 어설 션입니다. 다양한 지점에서 프로그램에 로그를 추가하고 얻은 결과를 예상 한 것과 비교합니다. 예를 들어 버그가 있다고 생각하는 함수가 처음부터 호출되는지 확인하십시오. 메서드 시작 부분의 변수가 당신이 생각하는 것과 같은지 확인하십시오. 중단 점과 달리 특별한 일이 발생하지 않는 많은 로그 행이 있어도됩니다. 나중에 로그를 통해 간단히 검색 할 수 있습니다. 예상과 다른 로그 라인에 도달하면 동일한 영역에 더 추가하십시오. 버그가있는 지역의 모든 줄을 기록 할 수있을만큼 충분히 작아 질 때까지 더 멀리 더 좁 힙니다.
어설 션은 최종 사용자에게 효과가 표시되는 것이 아니라 발생하는 잘못된 값을 트랩하는 데 사용할 수 있습니다. 잘못된 값을 빨리 포착할수록 해당 값을 생성 한 라인에 더 가까워집니다.
리팩터링 및 단위 테스트. 프로그램이 너무 크면 한 번에 하나의 클래스 또는 하나의 함수를 테스트하는 것이 좋습니다. 입력을 제공하고 출력을보고 예상과 다른 것을 확인하십시오. 전체 프로그램에서 단일 기능으로 버그를 좁힐 수 있다는 것은 디버깅 시간에 큰 차이를 만들 수 있습니다.
메모리 누수 또는 메모리 스톰 핑의 경우 런타임에이를 분석하고 감지 할 수있는 적절한 도구를 사용하십시오. 실제 손상이 발생한 위치를 감지하는 것이 첫 번째 단계입니다. 그런 다음 로그를 사용하여 잘못된 값이 도입 된 위치로 돌아갈 수 있습니다.
디버깅은 거꾸로 진행되는 프로세스임을 기억하십시오. 최종 결과 (버그)가 있고 그 이전의 원인을 찾습니다. 그것은 뒤로 작업하는 것에 관한 것이고 불행히도 디버거는 앞으로 나아갈뿐입니다. 좋은 로깅과 사후 분석을 통해 훨씬 더 나은 결과를 얻을 수 있습니다.