폐쇄 . 이 질문은보다
중점 이어야합니다. 현재 답변을 받고 있지 않습니다.
댓글
답변
디버깅에 대한 사고 방식과 태도는 아마도 가장 중요한 부분은 오류를 얼마나 효과적으로 수정하고 그로부터 무엇을 배울 것인지를 결정하기 때문입니다.
The Pragmatic Programmer 및 Code Complete 와 같은 소프트웨어 개발에 대한 고전은 기본적으로 동일한 접근 방식을 주장합니다. 모든 오류는 거의 항상 자신에 대해 배울 수있는 기회입니다. (초보자 만 컴파일러 / 컴퓨터를 먼저 비난하기 때문입니다).
그렇기 때문에 흥미로울 수있는 미스터리로 취급하십시오. 그리고 우리의 가정을 (우리 자신이나 다른 사람에게) 표현한 다음 필요하다면 모든 도구, 특히 디버거와 자동화 된 테스트 프레임 워크를 사용하여 우리의 가정을 하나씩 테스트함으로써 그 미스터리를 체계적으로 풀어야합니다. 그런 다음 수수께끼가 해결 된 후 모든 코드에서 비슷한 오류를 만들 었는지 살펴보면 더 나은 결과를 얻을 수 있습니다. 그리고 오류가 다시는 무의식적으로 발생하지 않도록 자동화 된 테스트를 작성합니다.
마지막 메모-저는 오류를 “버그”가 아닌 “오류”라고 부르는 것을 선호합니다.-Dijkstra는 후자의 용어를 사용하는 것에 대해 동료들에게 꾸짖 었습니다. 그것은 부정직하며, 우리 자신의 (조잡한) 생각 때문에 거기에있는 것이 아니라, 우리가 보지 않는 동안 악성하고 변덕스러운 버그 요정들이 우리 프로그램에 버그를 심었다는 생각을 뒷받침합니다. http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html
예를 들어 다음과 같이 언어를 정리할 수 있습니다. 더 이상 버그를 버그라고 부르지 않고 오류라고 부르는 것입니다. 그것이 속한 곳에 직각으로 비난을두기 때문에 훨씬 더 정직합니다. 오류를 범한 프로그래머와 함께. 프로그래머가 보지 않는 동안 악의적으로 몰래 들어간 버그에 대한 애니미즘 적 은유는 오류가 프로그래머 자신의 창작물 인 것처럼 위장하기 때문에 지적으로 부정직합니다.이 간단한 어휘 변경의 좋은 점은 그것이 엄청난 영향을 미친다는 것입니다. : 이전에는 버그가 하나 뿐인 프로그램이 “거의 정확함”이었던 반면, 나중에 오류가있는 프로그램은 (오류로 인해) “잘못된”것입니다.
댓글
답변
-
테스트 작성. 테스트는 버그를 예방하는 데 효과적 일뿐만 아니라 (제 경험상 TDD가 올바르게 수행하면 거의 모든 사소하고 어리석은 버그를 제거합니다) 디버깅에도 많은 도움이됩니다. 테스트는 디자인이 다소 모듈화되도록 강제하므로 문제를 훨씬 쉽게 분리하고 복제 할 수 있습니다. 또한 환경을 제어하므로 놀라움이 훨씬 적습니다. 또한 실패한 테스트 케이스를 받으면 “귀찮은 행동의 실제 이유를 정확히 파악했습니다.
-
디버거 사용 방법을 알아 봅니다. print 문은 어느 정도 수준에서 상당히 잘 작동 할 수 있지만 대부분의 경우 디버거가 매우 유용합니다 (한 번 사용법을 알고 있으면 print 문보다 훨씬 편안합니다.
-
문제에 대해 누군가에 대해 이야기하고, 단지 고무 오리 일지라도. 작업중인 문제를 말로 표현하도록 강요하는 것은 정말 기적입니다.
-
자신에게 시간 제한을 두세요. 예를 들어 45 분이 지나도 아무데도 갈 수 없다고 느끼면 잠시 다른 작업으로 전환하십시오. 버그로 돌아 오면 “이전에 고려하지 않았던 다른 가능한 솔루션을 볼 수 있기를 바랍니다.
댓글
답변
다른 답변은 대부분 마음에 들지만 수행 할 작업에 대한 몇 가지 팁은 다음과 같습니다. 당신이 그 중 하나를하기 전에. 시간을 절약 할 수 있습니다.
-
정말 버그가 있는지 확인합니다. 버그는 항상 시스템 동작과 요구 사항의 차이입니다. 테스터는 예상되는 동작과 실제 동작을 명확히 표현할 수 있어야합니다. 예상되는 동작에 대한 지원을 제공 할 수없는 경우 요구 사항이없고 버그가 없습니다. 누군가의 의견 일뿐입니다. 다시 보내주세요.
-
가능성을 고려하세요. 예상되는 동작이 잘못되었습니다. 이는 요구 사항을 잘못 해석했기 때문일 수 있습니다. 요구 사항 자체의 결함 (세부 요구 사항과 업무 요구 사항 간의 델타) 때문일 수도 있습니다. 이러한 사항도 다시 보낼 수 있습니다.
-
문제를 분리하세요. 경험 만이이를 수행하는 가장 빠른 방법을 가르쳐 줄 것입니다. 어떤 사람들은 거의 직감으로 할 수 있습니다. 한 가지 기본적인 접근 방식은 다른 모든 것을 일정하게 유지 (문제가 다른 환경에서 발생합니까? 다른 브라우저에서 발생합니까? 다른 테스트 지역에서 발생합니까? 하루 중 다른 시간에 발생합니까?) 또 다른 접근 방식은 스택 덤프 또는 오류 메시지를 보는 것입니다. 그건 그렇고, 시스템의 어떤 구성 요소가 원래 오류를 던 졌는지 형식이 지정되어 있습니다 (예 : 독일어로 된 경우 나에게 베를린에서 함께 일하는 제 3 자).
-
협력하는 두 시스템으로 범위를 좁힌 경우 트래픽 모니터 또는 로그 파일을 통해 두 시스템 간의 메시지를 검사하십시오. , 어떤 시스템이 사양에 따라 작동하고 어떤 시스템이 그렇지 않은지 확인합니다. 시나리오에 두 개 이상의 시스템이있는 경우 쌍별 검사를 수행하고 애플리케이션 스택을 “다운”하는 방식으로 작업 할 수 있습니다.
-
문제를 격리하는 것이 중요한 이유 문제는 사용자가 제어 할 수있는 코드 (예 : 타사 시스템 또는 환경)의 결함으로 인한 것이 아닐 수 있으며 가능한 한 빨리 해당 당사자가 인수하도록하기를 원한다는 것입니다. 이는 작업을 절약하고 가능한 한 짧은 시간 내에 해결을 달성 할 수 있도록 즉시 문제를 해결하기위한 것입니다. 다른 사람의 웹 서비스에 문제가 있다는 것을 알기 위해 10 일 동안 문제에 대해 작업하고 싶지는 않습니다.
-
실제로 결함이 있고 실제로 제어하는 코드에있는 것으로 확인 된 경우 마지막 “알려진 양호한”빌드를 찾아 문제를 추가로 격리 할 수 있습니다. 문제의 원인이 될 수있는 변경 사항에 대한 소스 제어 로그를 검사합니다. 이렇게하면 많은 시간을 절약 할 수 있습니다.
-
소스 제어에서 파악할 수없는 경우 지금이 디버거를 연결하고 코드를 단계별로 실행하여 파악해야합니다. 어차피 문제에 대해 꽤 잘 알고있을 가능성이 있습니다.
버그가 어디에 있는지 알고 수정을 생각할 수 있으면 여기에 수정 절차 :
-
문제를 재현하고 실패하는 단위 테스트를 작성합니다.
-
단위 테스트를 수정하지 않고 통과합니다 (애플리케이션 코드 수정).
-
회귀를 방지 / 감지하기 위해 테스트 스위트에 단위 테스트를 유지합니다.
답변
버그 재현도 중요하다고 생각합니다. 버그를 재현하는 모든 사례를 나열한 다음 버그 수정이 이러한 모든 사례를 포함하는지 확인할 수 있습니다.
답변
Why Programs Fail 이라는이 주제에 대해 내가 읽은 훌륭한 책이 있습니다.이 책은 과학적 방법을 적용하여 버그를 찾아 내고 해결하는 것부터 다양한 전략을 설명합니다. 버그, 델타 디버깅. 이 책의 또 다른 흥미로운 부분은 “버그”라는 용어가 없어진다는 것입니다. Zeller의 접근 방식은 다음과 같습니다.
(1) 프로그래머가 코드에 결함을 생성합니다. (2) 결함으로 인해 감염이 발생합니다 (3) 감염이 전파됩니다 (4) 감염으로 인해 실패가 발생합니다.
디버깅 기술을 향상시키고 싶다면이 책을 적극 추천합니다.
내 개인적인 경험으로 볼 때 우리 애플리케이션에서 많은 버그를 발견했지만 경영진은 단순히 우리를 계속 압박합니다. 새로운 기능을 제공합니다. 나는 “우리가 직접이 버그를 발견했는데 클라이언트가 아직 발견하지 못 했으므로 발견 할 때까지 그대로 두십시오”라는 말을 자주 들었습니다. 버그 수정에있어서 사전에 대응하는 것에 반대하는 것은 매우 나쁜 생각이라고 생각합니다. 실제로 수정을해야 할 때가되면 해결해야 할 다른 문제가 있고 더 많은 기능 관리가 최대한 빨리 처리되기를 원하기 때문입니다. 엄청난 스트레스와 소진, 궁극적으로 결함이있는 시스템으로 이어질 수있는 악순환에 빠졌습니다.
버그가 발견되면 커뮤니케이션도 또 다른 요소입니다. 이메일을 보내거나 버그 추적기는 모두 훌륭하지만 내 경험상 다른 개발자는 비슷한 버그를 발견하고 코드를 수정하기 위해 사용한 솔루션을 재사용하는 대신 (모두 잊어 버렸기 때문에) 자신의 버전을 추가합니다. 코드에 5 개의 서로 다른 솔루션이 있으며 결과적으로 더 부풀어지고 혼란스러워 보입니다. 따라서 버그를 수정할 때 몇 사람이 수정 사항을 검토하고 비슷한 문제를 수정 한 경우 피드백을 제공해야합니다. 이에 대처할 좋은 전략을 찾았습니다.
limist는
실용적인 프로그래머 는 버그 수정에 대한 흥미로운 자료를 제공합니다. 이전 단락에서 설명한 예를 사용하여 Software Entrophy 를 살펴 보겠습니다. 여기서 깨진 과부의 비유가 사용됩니다. 창이 나타나면 팀이 사전 조치를 취하지 않으면 문제를 해결하는 데 무관심해질 수 있습니다.
댓글
버그, 오류, 문제, 결함-무엇이라고 부르고 싶은지간에 별다른 차이가 없습니다. 그 이후로 문제를 고수하겠습니다. “내가 익숙한 일입니다.
- 문제에 대한 인식이 무엇인지 파악합니다. 고객의”밥은 아직 시스템에 없습니다 “에서”내가 시도 할 때 Bob에 대한 사용자 레코드를 생성합니다. 중복 키 예외로 인해 실패하지만 Bob은 “이미 거기에”있지 않습니다.
- 정말 문제인지 오해인지 파악합니다 (실제로 Bob은 그렇지 않습니다. ” t 거기에는 bob이라는 사람이 없으며 삽입이 작동합니다.)
- 문제를 재현하기 위해 따를 수있는 최소한의 신뢰할 수있는 단계를 시도합니다. – “사용자 레코드”Bruce “가있는 시스템에 사용자 레코드”Bob “이 삽입되면 예외가 발생합니다.”와 같은 것입니다.
- 이것은 테스트입니다. 가능하면 자동으로 반복해서 실행할 수있는 테스트 하네스는 디버깅 할 때 매우 중요합니다. 또한 특정 문제가 나중에 다시 나타나지 않도록 테스트 도구 모음의 일부로 만들 수도 있습니다.
- 디버거를 꺼내고 중단 점을 설정합니다. 테스트를 실행할 때 코드 경로를 파악하고, 무엇이 잘못되었는지 확인합니다. 그렇게하는 동안 테스트를 최대한 좁혀서 (이상적으로는 단위 테스트) 구체화 할 수도 있습니다.
- 문제 해결-테스트 통과를 확인하세요.
- 원래 문제를 확인하세요. 고객이 설명한대로 수정되었습니다 (매우 중요-문제의 일부만 수정했을 수 있음). 프로그램의 다른 측면에서 회귀를 도입하지 않았는지 확인합니다.
코드에 매우 익숙하거나 문제 또는 수정 사항이 명백한 경우 일부를 건너 뛸 수 있습니다.
귀중한 시간을 최대한 효율적으로 사용하고 검색 시간을 줄이고 코딩에 더 많은 시간을 할애 할 수 있도록 어떻게 접근해야합니까? ?
새로운 코드를 작성하는 것이 고품질의 작업 프로그램을 갖는 것보다 가치가 있다는 것을 의미하므로 문제가됩니다. 최대한 효율적으로 문제를 해결하는 것이 잘못된 것은 아니지만, 프로그램에 코드를 더 추가한다고해서 반드시 개선되는 것은 아닙니다.
코멘트