문제 진단을 위한 모범 사례 [닫기]

접근 방식은 문제 유형에 따라 달라집니다.

일반적으로 말하면"스마트하게 질문하는 방법Eric S. Raymond 및 Rick Moen 작성 “때로는 문제에 집중하고 문제의 중요한 부분을 고려했는지 확인하는 데 도움이 되는 유용한 팁이 있습니다.

디버깅 중 첫 번째 정보 소스는 시스템/응용 프로그램에서 작성한 로그 파일입니다. 일반적인 위치는 터미널 또는 입니다 /var/log/. 많은 애플리케이션은 다양한 유형의 로그 수준을 지원하며 사용 가능한 메시지를 찾을 수 없는 경우 로그 수준을 높여야 합니다. 일반적으로 -v더 많은 메시지를 얻으려면 자세한 정보를 표시하는 스위치가 있습니다 .

아직 사용할 것이 없나요? 구성 파일, 애플리케이션에 필요한 파일에 대한 권한을 확인하세요. 예를 들어 시스템 로거의 구성을 변경해야 할 수도 있습니다 /etc/syslog-ng.conf.

오류 메시지가 있는 경우 일반적으로 Google 검색을 통해 해당 문제를 논의하는 게시판 항목이나 웹 스레드로 연결됩니다. 아마도 그곳에서 해결책을 찾을 수 있을 것입니다. 프로젝트 사용자 메일링 리스트, 게시판, IRC 채널도 매우 유용합니다.

메시지 없이 앱이 충돌하는 경우가 있습니다. 코드를 읽고 수정하는 것 외에도 애플리케이션 흐름을 발견할 수 있는 훌륭한 도구가 있습니다 strace.

이 도구는 시스템 호출과 신호를 추적합니다. 애플리케이션이 오류를 포착하더라도 systrace에서 문제를 찾을 수 있습니다.

또 다른 방법은 디버깅 애플리케이션을 사용하는 것입니다 gdb. 당신은 고급 사용자여야 하며 이를 사용하기 위해 무엇을 해야 하는지 알고 있어야 합니다.

단일하고 보편적인 디버깅 원칙을 원한다면 시스템 작동 방식에 대해 가능한 한 많이 배우는 것입니다. 시스템의 각 구성 요소와 각 구성 요소의 오류 모드를 이해합니다. 최근에 변경한 구성 요소는 무엇인지, 자체적으로 변경되거나 실패했을 수 있는 구성 요소는 무엇인지 기록해 두십시오.

특정 정보를 찾고 있다면 echox의 답변에 유용한 정보가 많이 있습니다.

데이비드 아르간스(David Argans)가 썼다.아주 좋은 디버깅 책, 내 생각에는. 그것은 또한 세트를 포함합니다디버깅 가이드.

가장 중요한 것은 일반적인(영역) 지식과 경험이 패턴을 관찰하는 데 큰 도움이 된다는 것입니다. 사물이 어떻게 만들어지는지 연구하고 분해하세요. 정기적인 유지 관리를 수행합니다. 몇 가지 모호한 실험을 수행합니다. 읽고, 읽고, 읽으세요. 일하는 것. 계속 쓰세요. 다른 사람들이 문제를 해결하도록 도와주세요. 전투를 선택하세요. 침착함을 유지하세요. 웃다. :)