디버깅 : 특정 수정 사항이 작동 한 이유를 자세히 이해하고 있습니까? [닫은]

디버깅 할 때 때때로 변경 사항이 있음을 발견하고 왜 그 변경 사항이 프로그램의 일부 버그를 수정하는지 100 % 확신하지 못합니다. 일부 버그가 발생한 이유와 특정 변경으로 인해 해당 버그가 제거 된 이유에 대한 모든 세부 사항을 이해해야합니까? 또는 수정 프로그램이 왜 작동했는지에 대한 세부 정보를 모르고 프로그램을 작동시키는 것이 개발자에게 일반적입니까?

나는 몇 가지 버그가 발생하는 이유는 어떤 변화가 그 버그를 제거 된 이유에 대해 모든 단일 세부 사항을 이해하는 것이 필수적이라고 말할 것입니다, 그리고 정말 수정이 일을하는 이유에 대한 자세한 내용을 모른 채 작업 프로그램을 얻을 그것은 때때로 개발자들도 일반적입니다!

버그의 원인이나 변경 사항을 이해하지 못한 채 버그가 사라질 때까지 변경하는 기술을 종종 "부두 프로그래밍"이라고하며 칭찬이 아닙니다. 조사한 특정 사례에 대해 부분적으로 수정하는 대신 버그의 원인을 이해하지 못하는 경우 실제로 버그를 수정 했다고 확신 할 수있는 방법 은 없습니다.

최악의 경우, 버그를 옮기는 것 외에는 아무것도하지 않았습니다. 유니에서 첫 해 컴퓨팅에서 많은 학생들이 C와 포인터를 처음 배우고 있었을 때 포인터 버그가 변경되면 종종 표시가 멈추는 것을 기억합니다. 변경 사항은 포인터 버그가 다른 비트의 메모리에 스톰 핑되도록 메모리의 데이터 구조를 재정렬하기 때문입니다. 분명히 도움이되지 않았 음을 전혀 .

그러나 프로그래밍의 상업적 현실은 종종 고객이 버그를 수정 한 것을 만족시키는 것이 자신을 만족시키는 것보다 중요하다는 것입니다. 어떤 원인이 무엇인지 모르는 경우 수정 된 것을 선언하지 않는 것이 좋습니다 . 그러나 일부 코드에 문제가 있음을 알 수 있고 100 % 확실하지 않은 경우에도 코드를 다시 작성하면 특정 원인을 어떻게 클라이언트가 느린 진행에 대해 너무 큰 소리를 지르기 전에 다음 버그로 넘어 가야 할 때가 있습니다.

고객이 버그를 수정하는 데 너무 오래 걸리는 것에 대해 화가 났다고 생각하는 경우 고객이 수정했다고 주장하는 버그에 대해 얼마나 화가 났는지 또는 다른 것을 악화시키는 한 가지 수정에 대해 상상해보십시오. 해결 방법이 해결 방법이나 완화 방법 인 경우 고객은 일반적으로 해결 방법을 환영하지만 해결 방법에 대해 정직해야하며 실제로 해결하기 위해 필요한만큼의 로깅을 수행해야합니다.

수정했다고 확신하지만 수정이 왜 작동하는지 모르는 경우 다른 사람에게 문의하십시오. 내가 아는 대부분의 엔지니어 들은 그 뒤에 숨겨진 수수께끼 때문에 그런 질문을하는 것을 좋아 합니다.

버그가 없어 질 때까지 물건을 바꾸는 것은 일반적으로 나쁜 습관이 없지만 불행히도 일부 사람들에게는 현실입니다.

나는 그것이 무엇을하는지, 왜 그렇게하는지 이해하지 못하는 코드를 작성해서는 안된다는 강한 견해를 가지고 있습니다. 수정하려고했던 버그를 수정 했음에도 불구하고 다른 문제가 발생하지 않았 음을 어떻게 확신 할 수 있습니까?

일반적으로 문제 / 버그를 수정하기 전에 기본 원인 평가 / 분석을 수행하여 문제가 발생하는 이유와 복제 할 수 있는지 확인해야합니다. 그런 다음 코드를 읽고 코드로 인해 버그가 발생하는 이유를 이해해야합니다. 이해가되면 문제를 해결하고 변경 사항에 영향을 줄 다른 영역을 결정하는 방법을 시작할 수 있습니다. 단위 테스트가 실제로 도움이 될 수 있습니다!

사람들이 문제를 해결하기 위해 작성한 많은 코드 변경 사항을 보았지만 (안타깝게도) 개발자가 변경 한 내용의 전체 영향을 알지 못했기 때문에 불행히도 다른 문제가 발생했습니다. 이러한 많은 "수정 사항"은 원래 문제의 근본 원인을 모호하게하고 복잡성과 더 많은 버그를 도입합니다.

그렇게 말하면서, 나는 순수하게 협회에 의해 코드의 많은 문제를 해결했습니다. 내가 무언가를 변경 / 재 작업 / 리팩터링 한 곳에서 다른 뛰어난 버그가 수정되었습니다. 그래서 원래 원인이 무엇인지 모르지만, 난잡한 코드를 찾아서 수정했습니다.이 버그도 수정되었습니다. 나는 비즈니스의 무결성과 기능의 기술적 요구 사항을 보장하기 위해 단위 및 통합 테스트를 통해 이와 같은 변경 사항을 다룹니다.

또는 수정 프로그램이 왜 작동했는지에 대한 세부 정보를 모르고 프로그램을 작동시키는 것이 개발자에게 일반적입니까?

적어도 세 가지 큰 문제가 있습니다.

1. 코드를 이해할 수 있다는 생각을 포기하고 대신 문제가 사라지기를 기대하면서 부품을 움직이기 시작 하는 검은 마술 사고 방식으로 이어 집니다. 이것은 부모님이 야채를 더 많이 먹지 않을 정도로 저녁을 충분히 먹기를 바라면서 접시에 음식을 밀어 넣는 것과 동등한 프로그래밍입니다.

2. a) 문제가 무엇인지, b) 변경으로 인해 문제가 어떻게 해결되는지 이해하지 않으면 버그가 실제로 수정 되었거나 변경 사항에 의해 가려져 있다는 것을 알 수 없습니다 .

3. 버그는 수정되지 않았 으며 가까운 시일 내에 다시 물릴 것입니다.

두 가지 시나리오가 있습니다. 다른 작업을하고 버그가 발생하지 않았지만 다른 것이 깨지지 않은 한 그대로 들어가야합니다. 필요한 / 원하지 않는 일을했습니다. 예측할 수없고 설명 할 수없는 긍정적 부작용.

다른 하나는이 버그에 대해 작업하고 있으며 임의의 변경으로 인해 문제가 발생했다는 것입니다. 이전 코드가 무엇을 잘못했는지 모르는 경우 새 코드가 무엇을 잘못했는지 모를 것입니다.

두 번째 사례를 확인해야 할 이유를 실제로 생각할 수는 없습니다. 중대한 버그 인 경우 올바르게 해결하는 것이 중요합니다. 중요하지 않은 버그 인 경우 적어도 "수정"에 중요한 버그가 발생하지 않았 음을 확신 할 수 있습니다.

또는 수정 프로그램이 왜 작동했는지에 대한 세부 정보를 모르고 프로그램을 작동시키는 것이 개발자에게 일반적입니까?

나는 요즘 매우 흔한 일이라고 생각합니다. Google과 Stackoverflow 때문입니다. 당신은 당신의 코드에 문제가 있습니다, 그냥 구글, 해결책을 찾고, 수정하고, 다음 문제로 넘어갑니다.