진단하고 수정하기 전에 모든 결함을 재생해야한다고 주장하는 것이 합리적입니까?

저는 소프트웨어 제품 회사에서 일합니다. 우리는 제품을 구현하는 대기업 고객을 보유하고 있으며 고객을 지원합니다. 예를 들어, 결함이있는 경우 패치 등을 제공합니다. 즉, 이는 일반적인 설정입니다.

최근에, 우리 제품의 클러스터 구현에서 동시 데이터베이스 액세스와 관련된 로그 파일에서 고객이 발견 한 예외에 관한 티켓이 발행되어 나에게 할당되었습니다. 따라서이 버그가 발생하면이 고객의 특정 구성이 중요 할 수 있습니다. 고객으로부터 얻은 것은 로그 파일뿐입니다.

팀에 제안한 접근 방식은 고객과 유사한 구성 설정에서 버그를 재현하고 비슷한 로그를 얻는 것입니다. 그러나 시간이 많이 걸리고 VM에서 서버 클러스터를 시뮬레이트해야하므로 버그를 재현 할 필요가 없다는 접근 방식에 동의하지 않습니다. 팀은 스레드 코드 및 / 또는 트랜잭션이 안전하지 않은 코드의 위치를 ​​확인하고 발생하는 환경과 같은 클러스터 구현이 아닌 간단한 로컬 개발로 변경 작업을 수행하기 위해 단순히 "코드를 따르십시오"라고 제안합니다. 버그의 근원.

나에게, 가시적이고 명백한 표현 (런타임 재현)이 아닌 추상 청사진 (프로그램 코드)으로 작업하는 것이 어려워 보이므로 일반적인 질문을하고 싶었습니다.

진단하고 수정하기 전에 모든 결함을 재현하고 디버깅하는 것이 합리적입니까?

또는:

수석 개발자 인 경우 멀티 스레드 코드를 읽고 응용 프로그램을 실행하고 다른 사용 사례 시나리오를 직접 테스트하고 단계별로 테스트하지 않고 모든 사용 사례 시나리오에서 수행하는 작업에 대한 정신적 인 그림을 만들 수 있어야합니다. 코드를 한 줄씩? 아니면 그런 종류의 작업 환경을 요구하는 가난한 개발자입니까?

sissies에 대한 디버깅입니까?

제 생각에는 인시던트 티켓에 대한 응답으로 제출 된 모든 수정 사항은 가능한 한 원래 환경에 가깝도록 시뮬레이션 된 환경에서 테스트해야합니다. 그것이 실제로 문제를 해결할 것이라는 것을 어떻게 알 수 있습니까? 그것은 에어백이 실제로 작동한다는 것을 입증하기 위해 더미로 차량을 충돌 테스트하지 않고 새로운 차량 모델을 출시하는 것과 같습니다.

마지막으로, 당신이 저에게 동의한다면 :

내 접근 방식이 합리적이고 보수적이며 방 탄성이 있음을 확신시키기 위해 팀과 어떻게 대화해야합니까?

진단하고 수정하기 전에 모든 결함을 재현하고 디버깅하는 것이 합리적입니까?

최선을 다해야합니다. 때로는 너무 복잡해서 정확하게 재현 할 수없는 조건과 환경이 있다는 것을 알고 있지만 가능하면 확실히 시도해야합니다.

버그를 재생산하지 않고 직접 본 경우 실제로 수정했다고 100 % 확신 할 수 있습니까? 제안 된 수정 프로그램 에서 원래 결함 을 실제로 재현 하려고 시도 하지 않으면 나타나지 않는 다른 미묘한 버그가 발생할 수 있습니다.

수석 개발자 인 경우 응용 프로그램을 실행하고 다른 사용 사례 시나리오를 직접 테스트하고 단계별로 진행하지 않고 모든 사용 사례 시나리오에서 수행하는 작업에 대한 (멀티 스레드) 코드를 읽고 정신적 인 그림을 만들 수 있어야합니다. 코드는 한 줄씩? 아니면 그런 종류의 작업 환경을 요구하는 가난한 개발자입니까? sissies에 대한 디버깅입니까?

그것이 유일한 접근 이라면 코드를 "머리로"실행하는 사람을 믿지 않을 것입니다 . 시작 하기 좋은 곳 입니다. 버그를 재생하고, 고정하고 보여주는 용액을 다시 발생 버그를 방지 함 -가해야하는 경우 즉 종료 .

내 접근 방식이 합리적이고 보수적이며 방 탄성이 있음을 확신시키기 위해 팀과 어떻게 대화해야합니까?

그들이 버그를 재생산하지 않았다면, 그것이 수정되었다는 것을 확실히 알 수 없기 때문입니다. 그리고 고객이 돌아와서 버그가 여전히 존재한다고 불평하는 경우 이는 좋은 일 이 아닙니다 . 결국, 그들은이 문제를 해결하기 위해 큰 $$$ (내가 가정)를 지불하고 있습니다.

당신이 경우 실패 제대로 문제를 해결하기 위해, 당신은 (어느 정도) 고객과의 깨진 믿음을했습니다 당신의 시장에서 경쟁이있는 경우, 그들은 당신의 고객을 유지하지 않을 수 있습니다.

문제의 버그가 수정되었는지 어떻게 확인하려고합니까? 테스트되지 않은 코드를 사용자에게 제공하여 알아 내고 싶습니까? 오류를 재현하지 못한 테스트 설정은 오류가 없음을 보여줄 수 없습니다. 반드시 전체 클라이언트 환경을 재현 할 필요는 없지만 오류를 재현하기에는 충분해야합니다.

수정하기 전에 모든 버그를 재현하려고 시도하는 것이 합리적이지 않다고 생각합니다. 그러나 그것을 재현하려고 시도 할 수 없다면 블라인드 패치가 좋은 아이디어인지 아닌지에 대한 비즈니스 결정이 더 커집니다.

이상적으로는 최소한 버그가 수정되었는지 테스트 할 수 있도록 각 버그를 재현 할 수 있기를 원합니다.

그러나 ... 항상 가능하거나 물리적으로 가능한 것은 아닙니다. 특히 각 설치가 고유 한 '엔터프라이즈'유형 소프트웨어의 경우. 비용 / 혜택 평가도 있습니다. 몇 시간 동안 코드를 살펴보고 중요하지 않은 문제에 대한 몇 가지 교육 된 추측은 기술 지원 팀이 몇 주 동안 고객의 환경을 정확하게 복제하고 복제 할 수 있도록 고객의 환경을 설정하고 복제하는 데 소비하는 시간보다 훨씬 저렴할 수 있습니다. 문제. '엔터프라이즈'세계에서 일할 때 고객의 설정을 복제 할 방법이 없었기 때문에 종종 코더를 날려 사이트에 버그를 수정하게했습니다.

따라서 가능하면 복제하십시오. 그러나 가능하지 않은 경우 시스템에 대한 지식을 활용하고 코드에서 범인을 식별하십시오.

나는 버그를보기 위해 오류를 재현해야한다고 생각하지 않습니다. 앞에서 언급했듯이 문제를 디버깅하는 방법에는 여러 가지가 있으며 모두 사용해야합니다. 그들이 당신에게 로그 파일을 줄 수 있었다는 것을 행운으로 생각해야합니다! 당신이나 당신 회사의 누군가가 버그를 재현 할 수 있다면 좋습니다! 그렇지 않은 경우 여전히 로그를 구문 분석하고 오류가 발생한 환경을 찾아야합니다. 동료가 제안한대로 코드를 읽고 버그가 발생할 수있는 조건을 파악한 다음 시나리오를 직접 만들 수 있습니다.

그러나 테스트되지 않은 실제 수정 사항은 해제하지 마십시오. 모든 변경은 표준 개발자, QA 테스트 및 통합 테스트 루틴을 거쳐야합니다. 테스트하기 어려울 수 있습니다-멀티 스레드 코드를 언급했습니다.이 코드는 디버깅하기가 어렵습니다. 테스트 구성 또는 환경을 작성하기위한 귀하의 접근 방식에 동의합니다. 코드에서 문제점을 발견 한 경우 환경을 작성하고 문제점을 재현하며 수정 사항을 테스트하는 것이 훨씬 더 간단합니다.

나에게 이것은 디버깅 문제가 아니라 고객 서비스 문제입니다. 고객으로부터 버그 보고서를 받았습니다. 문제를 찾아서 해결하기 위해 실사를해야 할 책임이 있습니다.

내 생각에 ... 의사 결정자로서 귀하는 귀하의 입장을 정당화 할 수 있어야합니다. 제 3 라인 지원 부서의 목표가 고객의 노력으로 최단 시간 내에 버그를 수정하는 것이라면 모든 접근 방식이 해당 목표를 준수해야합니다. 또한, 접근 방식이 가장 빠른 예상 결과를 제공하는 것으로 입증 될 수 있다면 팀을 설득하는 데 아무런 문제가 없어야합니다.

지원 작업을 해본 결과, 클라이언트가 버그를 일관되게 재현하기 위해 수행 한 작업에 대한 "스크립트"와 버그를 일으킨 후보 예제를 지속적으로 제공 할 수있을 것이라고 항상 합리적으로 기대했습니다.

시스템에 익숙하지 않고 코드에 대한 배경 지식이 없다면 첫 번째 단계는 가능한 오류의 원인을 식별하는 것입니다. 후보 코드를 식별하기에는 로깅이 충분하지 않을 수 있습니다. 클라이언트에 따라 문제가되는 코드의 위치에 대한 추가 정보를 제공하는 로그 파일을 다시 제공 할 수 있도록 디버그 버전을 제공하는 경향이 있습니다.

코드 블록을 빠르게 식별 할 수 있으면 흐름의 시각적 매핑으로 코드를 파악하기에 충분할 수 있습니다. 그렇지 않다면 단위 테스트 기반 시뮬레이션으로 충분할 수 있습니다. 특히 클라이언트 복제 환경을 설정하는 데 시간이 덜 소요될 수 있습니다. 특히 문제의 복제 가능성이 많은 경우에 그러합니다.

귀하의 접근 방식은 제안 된 솔루션의 조합이어야하며 언제 종료하고 다음 단계로 진행해야 하는지를 아는 것이 작업을 효율적으로 수행하는 데 중요하다는 것을 알 수 있습니다.

팀이 버그를 더 빨리 발견 할 수있는 기회가 있다면 버그를 수정하는 데 걸리는 시간에 큰 영향을 미치지 않는 적절한 시간 범위를 제공한다는 개념을 팀이 지원할 것이라고 확신합니다. 당신이 복용 경로.

진단하고 수정하기 전에 모든 결함을 재현하고 디버깅하는 것이 합리적입니까?

나는 몇 가지 경고와 함께 예라고 말합니다.

• 코드를 읽고 문제가 될 수있는 장소를 찾는 것이 좋습니다. 패치를 작성하여이를 클라이언트로 보내 문제가 해결되는지 확인하십시오. 이 방법이 계속 실패하면 다른 옵션을 조사해야 할 수도 있습니다. 그냥 당신이 해결 될 수있는 동안 기억 버그가되지 않을 수도 있습니다 보고 된 버그.
• 이유 내에서이를 재현 할 수없고 코드에서 적신호를 찾을 수 없으면 고객과 좀 더 긴밀한 조정이 필요할 수 있습니다. 사이트 디버깅을 수행하기 전에 고객 사이트로 나갔습니다. 최고의 개발 환경은 아니지만 때로는 문제가 환경적인 경우 문제를 일관되게 재현 할 수있을 때 정확한 원인을 찾는 것이 가장 쉬울 것입니다.

나는이 시나리오에서 고객의 테이블에있었습니다. 저는 엄청나게 큰 Oracle 데이터베이스 클러스터 (수 테라 바이트의 데이터와 하루 수백만 개의 레코드 처리)를 사용하는 미국 관공서에서 일하고있었습니다.

우리는 재현하기 매우 쉬운 이상한 문제에 부딪쳤다. 버그를 Oracle에보고하고 몇 주 동안 버그를주고 받아 로그를 보냈습니다. 그들은 문제를 재현 할 수 없다고 말했지만, 문제를 해결할 수있는 몇 가지 패치를 우리에게 보냈습니다. 그들 중 누구도하지 않았습니다.

그들은 결국 현장에서 문제를 디버깅하기 위해 두 명의 개발자를 우리 위치로 옮겼습니다. 그리고 버그의 근본 원인이 발견되고 이후 패치가 문제를 올바르게 해결했습니다.

문제에 대해 긍정적이지 않은 경우 솔루션에 대해 긍정적일 수 없습니다. 적어도 하나의 테스트 사례 상황에서 문제를 안정적으로 재현하는 방법을 알면 오류의 원인을 알고 있음을 증명할 수 있으므로 후속 결함으로 인해 문제가 해결되었다는 것을 증명할 수 있습니다. 수정 사항을 적용한 후 동일한 테스트 케이스에서 오류가 발생했습니다.

즉, 경쟁 조건, 동시성 문제 및 기타 "비결정론 적"버그는 개발자의 복사본보다로드가 많고 복잡한 시스템에서는 드물게 발생하기 때문에 이러한 방식으로 해결하기가 가장 어렵습니다. 동일한 시스템에서 나중에 작업을 다시 실행하면 프로그램이 사라집니다.

종종 무작위 버그처럼 보이는 것은 결정적인 원인을 갖게되므로, 일단 알게되면 버그를 결정적으로 재현 할 수 있습니다. 이것을 무시하는 것, 진정한 Heisenbugs (멸균되고 모니터링되는 환경에서 테스트를 시도 할 때 사라지는 무작위 버그)는 99.9 %의 타이밍 관련이며, 일단 이해하면 앞으로 나아갈 길이 더 명확 해집니다. 코드 실행 중에 다른 단어가 가장자리에 닿으면 실패 할 수있는 것들을 스캔하고 그러한 취약점을 발견하면 테스트에서 악용하여 재생하려는 동작이 나타나는지 확인하십시오.

이러한 상황에서는 상당량의 심층 코드 검사가 일반적으로 요구됩니다. 코드의 작동 방식에 대한 선입견을 버리고 코드를 살펴보고 클라이언트가 관찰 한 방식으로 실패 할 수 있는 시나리오를 상상 해야 합니다 . 각 시나리오에 대해 현재 자동화 된 테스트 환경 내에서 효율적으로 실행할 수있는 테스트를 개발하십시오 (즉,이 테스트에 대해서만 새 VM 스택이 필요하지 않음). 예상 한 바에 따라이 코드가 클라이언트 문제의 원인 일 수 있음을 증명하거나 반증합니다.) 이것은 소프트웨어 엔지니어를위한 과학적인 방법입니다. 관찰, 가설, 테스트, 반영, 반복.

진단하고 수정하기 전에 모든 결함을 재현하고 디버깅하는 것이 합리적입니까?

아니요, 매우 확실하지 않습니다. 그것은 어리석은 정책 일 것입니다.

내가 당신의 질문과 제안으로 볼 수있는 문제는 그들이 서로를 구별하지 못한다는 것입니다.

• 버그 리포트
• 실패 ( 오류 )
• 버그 (때때로 오류 라고도 함 )

버그 리포트는 버그에 대한 통신입니다. 누군가가 무언가 잘못되었다고 생각한다는 것을 알려줍니다. 무엇이 잘못되었는지에 대해 구체적이거나 구체적이지 않을 수 있습니다.

버그 보고서는 실패의 증거입니다.

실패는 무언가 잘못 사건입니다. 특정 오작동이지만 원인이 무엇인지에 대한 단서가있는 것은 아닙니다.

오류는 버그로 인해 발생할 수 있습니다.

버그는 실패의 원인이다; 미래에 발생하는 장애를 방지하기 위해 원칙적으로 변경 될 수있는 것.

때로는 버그가보고 될 때 원인이 즉시 명확 해집니다. 이 경우 버그를 재현하는 것은 무의미합니다. 다른 경우에는 원인이 명확하지 않습니다. 버그 보고서에 특정 실패가 설명되어 있지 않거나 실패한 것이 원인이 무엇인지에 대한 단서를 제공하지 않습니다. 그러한 경우, 귀하의 조언이 정당하다고 생각합니다. 그러나 항상 그런 것은 아닙니다. 첫 번째 로켓 이 충돌 한 원인 (제어 소프트웨어의 특정 버그) 을 조사하기 전에 두 번째 $ 370 백만의 우주 로켓 충돌을 주장하지는 않습니다 .

또한 그 사이에는 모든 종류의 사례가 있습니다. 예를 들어, 버그 보고서가 이미 알고 있지는 않지만 이미 알고있는 잠재적 인 문제가 중요한 역할을 할 수 있다고 제안하는 경우,이를 자세히 살펴 보는 데 충분한 동기가 될 수 있습니다.

따라서 까다로운 경우에는 재현성을 주장하는 것이 현명하지만 엄격한 정책으로 시행하는 것은 현명하지 않습니다.

소프트웨어 개발의 다른 모든 것과 마찬가지로 정답은 타협입니다.

이론적으로 버그가 존재한다는 것을 증명할 수없는 경우 버그를 수정하려고 시도해서는 안됩니다. 그렇게하면 궁극적으로 아무것도 해결하지 못하는 코드를 불필요하게 변경할 수 있습니다. 그리고 그것을 증명한다는 것은 먼저 그것을 재현 한 다음 수정 사항을 작성하고 적용한 후 더 이상 발생하지 않음을 보여줍니다. 여기에서 당신의 직감은 올바른 방향으로 당신을 조종하고 있습니다-당신이 당신의 고객의 문제를 해결했다는 것을 확신하고 싶다면, 그 원인을 먼저 알아야합니다.

실제로는 항상 가능하지는 않습니다. 아마도 버그는 수십 명의 사용자가 동시에 코드에 액세스하는 대규모 클러스터에서만 발생합니다. 아마도 버그를 유발하는 특정 데이터 세트에 대한 특정 데이터 작업 조합이있을 수 있으며 이것이 무엇인지 전혀 모릅니다. 아마도 고객은 버그가 나타나기 전에 100 시간 동안 대화식으로 프로그램을 대화식으로 실행했을 것입니다.

어떤 경우 든, 작업을 시작하기 전에 부서에서 버그를 재현 할 시간이나 돈이 없을 가능성이 높습니다. 많은 경우에, 그것은 코드의 버그가 있음을 훨씬 더 분명 당신, 개발자에게있어 당신 포인트 올바른 상황. 문제를 진단 한 후에는 돌아가서 문제를 재현 할 수 있습니다. 이상적이지는 않지만 동시에 선임 개발자로서의 일부는 코드를 읽고 해석하는 방법을 알고 부분적으로 이러한 종류의 묻힌 버그를 찾는 것입니다.

내 의견으로는, 당신은 질문의 잘못된 부분에 집중하고 있습니다. 문제의 버그 를 궁극적으로 재현 할 수 없다면 어떻게해야 합니까? "네, 우리는 당신이 프로그램을 추락했다는 것을 알고 있지만 그것을 재현 할 수 없으므로 버그가 아닙니다."라는 말을 듣는 것보다 고객에게 더 실망스러운 것은 없습니다. 고객이이 말을 들으면 "소프트웨어가 버그가 있음을 알고 있지만 버그를 수정하고 고칠 수 없으므로 손가락을 엇갈리게됩니다"라고 해석합니다. 보고 된 버그를 "재현 불가능"으로 닫거나 "재현 불가능"으로 닫는 것이 더 좋으면 안정성을 향상시키기 위해 합리적인 변경을 했습니까?

매우 구체적인 오류 메시지 등으로 오류가 분명하고 명백하며 사소한 경우가 아니면 사용자 나 관리자가 오류를 복제 할 수없는 경우 버그를 수정하는 것이 매우 어렵습니다.

또한 단계를 복제 할 수없는 경우 버그가 수정되었음을 어떻게 증명할 수 있습니까?

귀하의 경우의 문제는 사용자가 오류가 어떻게 발생했는지, 즉 어떤 작업을 수행하는 화면에서 알 수 없다는 것입니다. 그들은 단지 로그를 가지고 있습니다.

나는 당신의 요점이 합리적이라고 생각합니다. 정신력이 있다면 급여를 받고 있지 않을 수도 있습니다.

나는 당신이이 걸릴 오류 복제 할 수없이 당신의 상사에게해야한다고 생각 시간의가 알 수없는 양 을 알아 내기를하고, 없다 전혀 garantee 는 뜻.

문제는 당신의 동료가 운 이없는 버그를 찾아서 고칠 때입니다.

그것을 극도로 가져 가서 코드를 작성할 때 코드에서 훨씬 일찍 버그를 발견했다고 가정하자 . 그런 다음 바로 거기에 고정시키는 것에 대한 자격이 없을 것입니다. 방금 작성한 코드에 논리적 인 결함이 있으며 원하는 것을 수행하지 않습니다. 실제로 버그임을 나타 내기 위해 전체 환경을 설정할 필요가 없습니다.

이제 버그 리포트가 나타납니다. 할 수있는 몇 가지가 있습니다. 그중 하나는 코드로 돌아가서 다시 읽는 것입니다. 이제이 두 번째 판독에서 코드에서 즉시 버그를 발견한다고 가정하십시오. 버그는 의도 한대로 수행하지 않으며 코드를 작성할 때 알아 차리지 못했습니다. 그리고 방금 들어온 버그를 완벽하게 설명합니다! 당신은 수정합니다. 20 분 걸렸습니다.

버그 리포트를 일으킨 버그가 수정 되었습니까? 100 % 확신 할 수는 없지만 ( 이 같은 일을 일으키는 두 가지 버그 가있을 수 있습니다 ) 아마도 그럴 것입니다.

할 수있는 또 다른 일은 고객의 구성은 물론 며칠 동안 할 수있는 작업을 재현하고 결국에는 버그를 재생산하는 것입니다. 대부분의 경우 버그를 재현 할 수 없다는 타이밍 및 동시성 문제가 있지만 많은 시간을 투자하고 때로는 같은 일이 발생하는 것을 볼 수 있습니다. 이제 디버깅을 시작하고 코드에서 오류를 찾아 환경에 배치 한 후 여러 번 다시 시도하십시오. 더 이상 버그가 발생하지 않습니다.

버그 리포트를 일으킨 버그가 수정 되었습니까? 여전히 100 % 확신 할 수는 없습니다. 하나는 실제로 고객이했던 것과 완전히 다른 버그를 보았을 것입니다. 두 개는 자주 시도하지 않았으며 세 개는 구성이 여전히 약간 다르고 이 시스템에서는 고정되었지만 고객은 아닙니다.

따라서 확실성은 확실하지 않습니다. 그러나 첫 번째 방법은 빠른 방법 (당신은 빨리도 고객에게 패치를 제공 할 수 있습니다)이며, 방법은 저렴하고 있는 경우 는 증상을 설명하는 명확한 코딩 버그를 발견, 너무 문제를 찾을 실제로 가능성이 높습니다.

따라서 다릅니다. 테스트 환경을 설정하는 것이 저렴하다면 (또는 더 나은 경우 : 문제를 보여주는 자동화 된 테스트) 그렇게하십시오. 그러나 비용이 비싸거나 버그 쇼가 예측할 수없는 상황이라면 항상 코드를 먼저 읽음으로써 버그를 찾는 것이 좋습니다.

질문을 읽고, 나는 당신의 위치와 당신의 팀 사이에 근본적인 반대는 보이지 않습니다.

• 예, 클라이언트 설정에서 발생하는 문제를 재현하기 위해 최선을 다해야합니다. 그러나 최선의 노력은 시간 상자를 정의해야하며 실제로 로그에 문제를 재현하기에 충분한 데이터가 없을 수 있다는 것입니다.

  그렇다면 모두이 고객과의 관계에 따라 다릅니다. 그것은 당신이 그에게서 다른 것을 가지고 있지 않을 수 있으며, 진단 도구와 실패한 시스템에서 실행할 수있는 능력을 갖춘 사이트에 개발자를 보낼 수 있습니다. 일반적으로 우리는 중간에 있고 초기 데이터가 충분하지 않으면 더 많은 것을 얻을 수있는 방법이 있습니다.

• 예, 선임 개발자는 코드를 읽을 수 있어야하며 로그 내용에 따라 문제의 원인을 찾을 수 있습니다. 실제로 코드를주의 깊게 읽은 후 문제를 나타내는 단위 테스트를 작성하는 것이 종종 가능합니다.

  이러한 단위 테스트를 작성하는 것은 파괴적인 기능 환경을 재현하는 것만큼이나 좋습니다. 물론,이 방법은 당신이 무엇이든 찾을 것이라고 보장하지 않습니다. 일부 멀티 스레드 소프트웨어에서 오류를 발생시키는 정확한 이벤트 시퀀스를 이해하는 것은 코드를 읽는 것만으로는 찾기가 어려울 수 있으며 실시간 디버깅 기능이 중요해질 수 있습니다.

요약하자면, 나는 두 가지 접근법을 동시에 시도하고 문제를 나타내는 (그리고 나중에 수정되었음을 보여주는) 라이브 시스템 또는 문제에 대한 일부 파괴 단위 테스트 (또한 수정 후에도 수정 됨)를 요구합니다.

코드를 수정하고 야생으로 보내려고하면 실제로 매우 위험 해 보입니다. 나에게 발생한 일부 유사한 경우 (내부 결함을 내부적으로 재현하지 못한 경우), 수정 프로그램이 잘못 진행되어 고객 문제를 해결하지 못했거나 다른 예상치 못한 부정적인 결과가 발생한 경우 지원 팀이 실제 문제를 찾도록 도와야합니다. 필요한 경우 고객과의 거래를 포함합니다.

더 자세한 로깅이 필요한 것 같습니다.

로깅을 더 추가해도 디버그 (또는이 경우 상황 재현)가 필요하지는 않지만 실제로 무엇이 잘못되었는지에 대한 훨씬 나은 통찰력을 제공합니다.

특히 복잡한 / 스레딩 상황이나 디버거를 사용할 수없는 경우 "debug by printf ()"로 돌아가는 것이 유일한 해결책 일 수 있습니다. 이 경우 가능한 한 많이 (필요한 것 이상) 기록하고 겨에서 밀을 걸러내는 좋은 도구를 갖추십시오.

진단하고 수정하기 전에 모든 결함을 재현하고 디버깅하는 것이 합리적입니까?

아직 명확한 용어로 아무도 말하지 않았으므로 절대로 그렇지 않습니다!

소프트웨어 개발의 다른 모든 것과 마찬가지로 버그 수정은 시간, 위험 및 비용을 염두에 두어야합니다. 이것들 사이의 균형을 찾는 것은 개발자의 작업 설명의 절반입니다.

일부 버그는 2 일 동안은 중요하지 않지만 10 분 동안 수정하면 충분합니다. 다른 버그는 비 결정적이며 이미 테스트 환경에서 버그가 수정되었음을 증명할 수 없다는 것을 알고 있습니다. 테스트 환경을 설정하는 데 2 ​​일이 걸리면 이러한 버그에 대해서는 수행하지 않습니다. 대신 2 일 대신 5 분 내에 테스트 환경을 설정하는 방법을 찾는 등보다 똑똑한 작업에 시간을 투자합니다.

물론 잘못하면 고객이 $ 100'000 +를 잃는 버그가 있습니다. 그리고 클라이언트가 매 시간마다 $ 100'000 +를 잃는 버그는 수정되지 않았습니다. 버그를보고 결정을 내려야합니다. 모든 버그를 동일하게 취급하는 담요 설명이 작동하지 않습니다.

아주 좋은 질문입니다! 내 의견은 당신이 문제를 재현 할 수 없다면 당신이 만든 수정 사항이 다음과 같지 않을 것이라고 100 % 확신 할 수 없다는 것입니다.

a) 실제로 문제를 해결하십시오. b) 다른 버그를 만듭니다

버그가 발생하여 수정하는 경우가 있으며 테스트를 귀찮게하지 않습니다. 나는 그것이 작동한다는 것을 100 % 알고 있습니다. 그러나 QA 부서에서 작동한다고 말할 때까지 여전히 버그가 있거나 수정 프로그램에서 생성 된 새 버그가있을 가능성이 있다고 생각합니다.

버그를 재현 할 수없고 새 버전을 설치하고 수정 된 것을 확인하면 100 % 확실하게 버그가 사라 졌다고 말할 수 없습니다.

나는 당신이 다른 사람들에게 설명하는 데 도움이되는 유추를 생각하기 위해 몇 분 동안 노력했지만 실제로 아무것도 생각하지 못했습니다. 정관 절제술은 재미있는 예이지만 같은 상황이 아닙니다 :-)

[버그 관련] 동시 데이터베이스 액세스, 클러스터 구현, 멀티 스레드

진단하고 수정하기 전에 모든 결함을 재현하고 디버깅하는 것이 합리적입니까?

나는 그것을 재현하려고 너무 많은 시간을 소비하지 않았다. 동기화 문제처럼 보이며 문제를 재현하는 방법을 찾고 디버거로 공격하는 것보다 추론 (문제가 발생하는 하위 시스템을 정확히 지정해야하는 것과 같은 로그에서 시작)을 통해 더 자주 발견됩니다. . 내 경험상 코드의 최적화 수준을 낮추거나 때로는 추가 계측을 활성화하면 버그가 나타나지 않도록 충분한 지연 또는 동기화 기본 요소가 부족할 수 있습니다.

예, 버그를 재현 할 방법이 없다면 버그를 고칠 수 없습니다. 그러나 고객이 고객에게 재생산 방법을 제공하지 않으면 동일한 결과는 있지만 근본 원인이 다른 유사한 제품을 찾고있을 수도 있습니다.

두 가지 활동 (코드 검토 및 테스트)이 필요하지만 충분하지 않습니다.

버그를 재현하려고 실험을 구성하는 데 몇 개월을 소비 할 수 있으며 코드를 직접 보지 않고 검색 공간을 좁히기위한 가설을 세운 경우에는 아무데도 가지 않을 수 있습니다. 코드에서 버그를 시각화하려는 배꼽을 응시하는 데 몇 달이 걸릴 수도 있고, 점점 더 조급 한 고객이 "아니오. "

일부 개발자는 다른 개발자보다 한 가지 활동 (코드 검토 대 테스트 구성)이 상대적으로 우수합니다. 완벽한 관리자는 버그를 할당 할 때 이러한 장점을 평가합니다. 팀 접근 방식이 더 유익 할 수 있습니다.

궁극적으로 버그를 재현하기위한 정보가 충분하지 않을 수 있으며 다른 고객이 비슷한 문제를 발견하여 구성 문제에 대한 더 많은 통찰력을 얻기를 바라는 동안 버그를 해결해야합니다. 버그를 본 고객이 실제로 수정을 원하면 더 많은 정보를 수집하기 위해 귀하와 협력 할 것입니다. 이 문제가 한 번만 발생한 경우 고객이 중요하더라도 우선 순위가 높은 버그가 아닐 수 있습니다. 때때로 버그가 작동하지 않는 것은 정보가 충분하지 않은 매우 모호한 결함을 찾기 위해 인력을 불 태우는 것보다 더 똑똑합니다.