10 시간 넘게 당황하게 만드는 정말 기괴한 오류를 어떻게 해결합니까? [닫은]


29

이해가 안되는 오류를 알고 있습니다. 그렘린처럼 보이는 곳이 칩 내부로 뛰어 들어 무언가를 엉망으로 만들었습니다. 산책, 물건 쓰기, 삼촌 부름?


3
설명이 정확할 수 있습니다. 재부팅하고 다시 시도하십시오!
NoChance

5
물론
William

5
10 시간의 임계 값을 결정한 이유는 무엇입니까? 한두 시간 안에 예상치 못한 행동을 일으키는 원인이 무엇인지 잘 모른다면 문제가있는 것입니다.
벡터

5
"가는 것이 힘들어지면, 힘든 사람은 잠을 자고 잠재 의식이 작용하게한다." -anon
Michael Easter

2
1. 도와 줄 사람을 구하십시오. 두 사람은 필수입니다. 2. 과도한 양의 디버그 명령문을 사용하여 좁 힙니다. 모든 단일 행 앞에는 segfaulted를 정확히 찾기 위해 디버그 매크로가 오는 파일이있었습니다.
SF.

답변:


9

정말 끔찍한 문제의 경우 내 전략은 일반적으로 다음과 같습니다.

  • 실험과 구글. 문제를 계속 해결하십시오. 대부분의 경우 1 시간 이내에 문제가 해결됩니다.

  • 그래서 그것은 효과가 없었습니다. 휴식을 취하다. 커피를 마시고 동료와 관련이없는 것에 대해 이야기하십시오. 당신의 마음에서 문제를 밀어 내십시오. 5 분 또는 10 분 후에 문제를 보면 약간 다른 관점에서 문제를보고있는 것입니다. 대부분의 경우 이것이 작동합니다.

  • 이 경우에는 그렇지 않습니다. 따라서 10 분에서 30 분 정도 더 살펴보십시오. 그런 다음 동료에게 전화하십시오. 그러나하기 전에 몇 가지 메모를하십시오. 문제를 설명하고 재현 한 다음 시도한 사항을 나열하고 가장 중요하게 시도했음을 증명하려고합니다. 먼저 드라 이런을하십시오. 코드에 약간의 북 마크를 설정하고 불필요한 공개 문서 등을 닫으십시오. 이런 방식으로 문제를 직접 해결할 수도 있고 문제를 설명 할 때 시간을 낭비하지 않을 수도 있습니다.

  • 동료에게 모든 가정을 증명하도록 요청하십시오. 그 세터가 실제로 호출되고 있습니까? 그 방법이 당신이 주장하는 것을 실제로 돌려주고 있습니까? 객체가 null이 아니라고 생각합니다-null이 아님을 보여주십시오.

  • 대부분의 경우 문제를 시연하면 모든 가능성을 시도하지 않았거나 동료가 실수를 보게 될 것임을 알 수 있습니다.

  • 그것이 시간이 지나면 진지해집니다. 수행하려는 작업, 시도한 작업 및 작동하지 않는 이유를 정확하게 기록하십시오. 이 내용을 모든 동료에게 이메일로 보내십시오. SO에 게시하십시오. 이 시점에서 문서는 완벽한 SO 질문이어야합니다.

  • 답변을 기다리는 동안 google google google. 질문의 모든 순열을 시도하십시오. 여러 탭을 엽니 다. 이 시점에서 답을 얻지 못할 수도 있지만 아이디어, 가능성, 문제에 접근하는 다양한 방법을 찾고 있습니다.

  • 5 시간 동안 문제에 대해 하루를 보낸 경우 다른 일을하십시오. 아마도 당신은 유용한 응답을 얻을 것입니다. 다음날 문제를 공격 할 때 분명합니다.

  • 그 중 아무것도 작동하지 않으면 다른 솔루션을 찾을 때입니다. 다른 방법, 다른 기술을 사용할 수 있습니다. 아마도 지금은 기능을 포기하는 것을 고려해야 할 것입니다. 시간별로 고객에게 청구하고 있습니까? 내부 앱에서 회사를 위해 일하고 있습니까? 이것을 소유자에게 이관하고 그들에게 "내가 이것에 대해 x 시간을 보냈는데 아무런 진전이 없었으며, 그에 따른 비용 혜택이 있습니까?"라고 말해야합니다. 당신은 상사에게 가고 싶지 않고 그들에게 돌아 서서 16 시간 동안 문제에 대해 이야기하고 싶지 않다고 말하고 싶지 않습니다. 더 일찍 알아 내야합니다.

  • 그리고 그것이 효과가 없다면? 유일하게 선택할 수있는 것은 문제를 해결하거나 업계 전문 지식을 찾는 것입니다. 트위터에서 기술 전문가에게 문의하십시오. 기술 제공 업체에 이메일을 보내십시오.


79

떠나다. 아니, 너의 일이 아니야! 일어나서 집에 가십시오. 당신은 하루 또는 주말에 끝났습니다. 다음 번 문제로 돌아 오면 20 개 중 19 번이 해결책이 1 시간 내에 나타납니다.


17
고무 더킹을 시도해 볼 수도 있습니다. en.wikipedia.org/wiki/Rubber_duck_debugging
Dave Nay

2
20 명 중 19 명. 내 최악의 문제는 해결되지 않았으며 해결되었습니다. 테스트 환경은 없었으며 운영 환경 전체 만 보여주었습니다. 몇 시간이 지나도 재현 할 수 없었습니다.
Loren Pechtel

3
당신을 자극하는 무언가로부터 벗어나는 것은 정말 어려울 수 있습니다. 그러나 저는 수년에 걸쳐 항상 최선의 방법이라는 것을 알았습니다. 잠재 의식은 당신이 먹고, 자고, 잘 지내고, TV를 시청하는 동안 문제를 해결할 수 있습니다. 그리고 다음날 (또는 다음날) 상황이 더 좋아집니다. 경고의 한 마디 : 당신이 떠나기 전에 정보를 모으는 것.… 떠나는 것은 그것을 무시하고 그것을 행하는 것과 같지 않습니다. 여전히 노력이 필요합니다!
quick_now

1
나는 한 시간에 대해 모른다. 나는 일반적으로 아침에 일어날 때 샤워에서 이러한 유형의 문제를 대부분 해결합니다. 두 번째로 가장 빈번한 것은 내가 밤에 거의 자고 마침내 그것에 대해 생각하지 못하게했을 때입니다.
SoylentGray

3
Neil deGrasse Tyson이 주최 한 매혹적인 NOVA Science NOW가 수면 과학에 대해 이야기했습니다. 그것은 몇 시간 동안 문제에 머리를 두드리고, 자고, 일어나서 즉시 해결하는 현상에 대해 논의했습니다. 우리가 잠을 자면 우리의 뇌는 여러 가지 각도에서 분석하면서 하루의 사건을 반복해서 돌립니다. 그 뒤에 남겨진 것은 실제로 우리가 완전히 새로운 방식으로 문제를보고, 실제로 문제를 해결할 수 있도록 도와주는 새로운 신경 경로입니다. 꽤 멋진.
Byrne Reese

44

10 시간이 지나기 전에 도움을받을 것입니다.

  1. 다른 사람, 다른 사람, 심지어 고무 오리 에게도 문제를 설명하십시오 .
  2. 다른 사람에게 코드를 보도록 요청하거나 코드를 단계별로 살펴 봅니다.
  3. 그것을 분리하십시오. 많은 것들을 삭제하고 문제가 다시 나타날 때까지 조금씩 다시 가져옵니다.
  4. 잠 좀 자요!

12
문제가 사라질 때까지 모든 것을 삭제 한 +1
요나

4
1 시간이 지나기 전에 그 중 하나를 수행해야합니다. 응시할수록 주현절을 겪을 가능성이 줄어 듭니다. 나는 보통 누군가와 이야기함으로써 문제를 해결합니다.
Ben

에 딱 맞다. 종종 문제를 먼저 설명함으로써 문제를 파악하거나 가까이 다가갑니다. StackOverflow 질문에 대한 문제에 대한 설명을 쓰는 동안 자주 발생합니다. 또한 축소 (절연)가 필요
하다가

17

한 단어 timebox는 무언가를 위해 일하는 데 제한된 시간을 설정하고, 해결되지 않으면 다른 것으로 넘어 가서 다음날 새로운 관점으로 돌아 오십시오.

그것과 또 다른 눈은 항상 당신이 무언가를 쳐다 보는 것보다 더 가치가 있습니다.

나는 한 자리에서 무언가를 해결하기 위해 45 분에서 1 시간 이상을 소비하지 않을 것입니다. 그것은 수익 감소 법을 위반합니다.


정말 감사합니다-위키 백과에 대한 타임 박스 기사를 읽었습니다. 매우 유용합니다.
Adel

7

다른 사람에게 문제를 설명하십시오.

다른 사람에게 문제를 설명함으로써 문제를 명확히해야합니다. 이렇게하면 종종 솔루션을 볼 수 있습니다.

(영국의 전문 컴퓨터 잡지 중 하나가이 목적을 위해 특별히 선임 프로그래머의 실물 크기 판지 컷 아웃 판매를 제안했습니다.)

나는자는 문제 (때로는 며칠 동안)가 도움이 될 수 있습니다.


1
"다른 사람"은 인간 일 필요는 없습니다. 때때로 나는 고양이에게 물건을 설명하고 아하! 문제가 있습니다.
DarenW

나도 고양이를 사야한다. 필요에 따라 머리를 긁도록 훈련했습니다.
Adel

누군가 실제로 Jon Skeet의 실물 크기 판지 컷 아웃을 만들어야합니다.
Don Roby

5

3 단계 계획이 있습니다.

  1. 커피 나 다른 맛있는 음료를 드십시오.
  2. 하루 종일 다른 일을하십시오.
  3. "친구에게 전화"하고 화이트 보드에 낙서하십시오.

이전 단계가 실패한 경우 각 단계는 에스컬레이션됩니다. 2 단계에서 작업 할 수있는 생산성이 거의 항상 있습니다.


좋은 조언! 그래서 "친구에게 전화하기"는 백만장 자와 같이 60 초로 제한되어야하기 때문에 인용됩니다. 나는 화이트 보드 아이디어도 좋아한다.
Adel

1
화이트 보드가 체계적으로 생각하는 데 도움이된다는 것을 알게되었습니다. 따옴표는 종종 친구가 같은 사무실에 있기 때문에 실제로 전화하는 것이 이상합니다. 그러나 그것은 TV 쇼에서 생명선처럼 느껴졌습니다.
Flexo

4

잠 들어

그렇지 않으면 근처에있는 사람에게 전화를 걸어 코드를 간단히 살펴보십시오.

종종 (코드부터) 찾기까지 오랜 시간이 걸리는 오류는 다른 사람들이 쉽게 찾을 수 있습니다.


3

일어나서 주변을 둘러보고 문제에 대해 생각하면 해결책을 찾는 데 도움이됩니다. 실제로 서 있는지 또는 간격인지에 관계없이 생각하는 동안 컴퓨터에서 벗어나십시오.


3

나는 일반적으로 세 가지 중 하나를 수행합니다.

  1. 도보 / 자전거를 타십시오 ... 일부는 컴퓨터에서 멀어집니다.
  2. 내 개나 고양이와 놀아
  3. 취미가 있다면 잠시 동안 그 일을하십시오.

세 사람 모두 자신이 처한 상황에서 자신을 산만하게하는 좋은 일을합니다. 나는 정신이 산만 해져서 잠재 의식적인 뇌가 잠시 동안 무언가를 씹게했습니다. 이것의 1 시간 정도 후에, bam, 해결책이 있습니다 :-).


3

정확한 결함을 목표로 테스트 하네스를 구축하고 격리

결함을 복제하는 동안 좋은 코드를 계속 제거하십시오. 정확한 코드를 대상으로 지정할 때까지 오류가 발생합니다. 그런 다음 코드를 추적하십시오.

권장 독서 : 실용 프로그래머 특히 10 장 : 추적 총알


이 모든 것이 좋고 훌륭하지만 버그가 생겨 재현 될 수 있다는 것은 당연한 일입니다. 지금까지 19 시간을 보냈다면 ... 결정적이고 체계적인 방식으로 문제를 재현 할 수있는 수단을 찾으려고한다면 어떨까요? 나에게 그것은 여기서 질문의 본질이다!
Newtopian

Pragmatic Programmer는 훌륭합니다
Adel

2

이 모든 제안은 훌륭합니다. 그러나 언급하지 않은 기술을 자주 사용합니다. 문제에 대한 생각을 정리할 목록을 만드십시오. 특히 끈적 끈적한 문제가있는 경우 일반적으로 사실, 가정, 질문, 증상 등과 같은 여러 목록을 작성합니다. 이런 방식으로 물건을 정리하는 과정에서 종종 내가 알지 못했던 가정을 발견합니다. 종종 잘못된 것으로 밝혀 짐), 내가 알지 못하는 질문, 확인할 수있는 다른 순열 등


2

편집하다:

짧은 대답 :

Q : 10 시간 이상 의아해하는 기괴한 오류를 어떻게 해결합니까?

A : 디자인을 이해하고, 코드를 알고, 디버거 사용법을 배우십시오.


설명:

"그렘린처럼 보이는 부분이 칩 속으로 뛰어 들어 무언가를 엉망으로 만들었습니다."

이런 일은 절대 일어나지 않아야합니다. 코드 인 경우 오류를 수정하기 전에 오류의 원인을 잘 알고 있어야합니다.

또한 코드를 작성할 때 이미 실패 할 가능성이있는 위치와 이유를 알고 있어야합니다.

동료에게 요청하고, SO에 게시하고, 단계를 다시 추적하고 롤백하고 휴식을 취하면 위에서 언급 한 모든 제안이 도움이 될 것입니다.

다른 것은 툴을 알고 있어야한다는 것입니다-디버깅 툴킷. 조건부 중단 점 및 시계 등을 사용하여 코드의 의심스러운 지점에 메시지를 기록하고 호출 스택을주의 깊게 검사합니다. 디버깅 기술은 추가 기능이 아니며 프로그래밍의 일부입니다.


자신의 단계를 되돌릴 수있는 것이 중요합니다. 고맙습니다!
Adel

> 걸음을 되돌릴 수있는 것이 중요합니다. 롤백 / 리트 레이싱이 가능한 핵심 요소는 SourceControl 소프트웨어입니다. 그것에 대해 진지하게 생각하고 가능하면 체크인시 의견을 남기도록 설정하십시오.
벡터

3
불행히도, 코드를 얼마나 잘 알고 있더라도 문제는 다른 사람의 (닫힌 소스) 코드와의 상호 작용입니다.
네이트 CK

2
+1 @Nate CK- 매우 그렇습니다. 최악의 유형의 버그는 의존했던 웹 서비스에서 일종의 횡설수설을 얻었을 때 발생합니다. 웹 서비스에서 경고없이 일부 기능을 미묘하게 변경 한 Saas 공급 업체가있었습니다. 코드가 어떻게 생겼는지 설명 할 때 개발자에게 전화로 자신의 버그를 수정하는 방법을 설명해야했습니다.
Morgan Herlocker

1
무엇을 결정하기 위해? 타사 코드에 문제가 있습니까? 그 부분은 비교적 쉽습니다. 어려운 부분은 어떤 조건에서 문제가 발생했는지, 어떻게 해결해야하는지 파악하는 것입니다. 소스가 없을 때 공급 업체가 응답하지 않으며 테스트 시스템에서 발생하지 않을 수 있습니다. 코드를 아는 것이 당신을 위해 모든 것을 해결할 것이라고 생각한다면, 당신은 그것을 다루지 않았을 것입니다.
네이트 CK

1

비슷한 문제, Objective-C의 명백한 메모리 손상으로 여러 시간 동안 어려움을 겪었습니다. 그러나 저와 제 동료들은 점심 식사를 위해 산책을했고 문제 (및 init 메소드에서 객체의 직렬화 해제와 관련된 특정 비트)를 설명하고 기본적으로 모든 문제를 나에게 설명했습니다.

(기술 세부 사항 : 기본적으로 객체를 초기화하고 자기 이외의 객체로 반환했기 때문에 두 개의 할당자가 있었지만 객체는 하나만 반환되었습니다. 그것도).


1
"자체가 아닌 다른 객체로 객체를 초기화하고 반환했습니다"-버그는 너무 큽니다! 당신은 그것을 100 번 이상보고 그것을 잡을 수 없습니다. 그러나 디버거에서 추적하여 두 개의 할당을 볼 수 없었습니까?
벡터

1

여기에 이미지 설명을 입력하십시오

목욕하다.

모든 로드니 맥케이의 팬?

그러나이 모든 답변에 공통점이 있다면 휴식을 취하고 다른 일을해야합니다 .

나는 그것이 당신의 잠재 의식에 문제를 강요하는 것으로 생각하고 싶습니다. 우리가 달리 모르는 경우에도 , 목욕을하는 것과 같은 다른 일을하고있을 때에도 우리의 생각은 계속해서 문제를 해결 합니다.


좋은 생각이야 .. 이제 상사에게 사무실에 수십 개의 수조 통을 넣어달라고하면 돼.
Dave Nay

칸막이 노동자의 군단에만 각각 그런 방이 있다면.
Adel

1

단계별로 조립하여 조립합니다. 누가 메모리 액세스에 대한 중단 점을 호출합니다. 그것은 보통 버그를 빨리 잡습니다.

그렇지 않다면, 산책하십시오.


1

이 모든 것들의 조합 :

  • 저리 가 뒤로 버너에 앉을 수 있도록 잠시 동안에서. 수면, 휴식, 식사, 산책 등 무엇이든 할 수 있습니다.

  • 문제점을 더 조사 하고, 다른 문제점은 무엇이며, 다른 증상은 무엇입니까?

  • 문제를 조사 하고 찾을 수있는 것을보십시오. 다른 키워드를 사용해보십시오

  • 다른 것을 시도하십시오 . 해결 방법. 다른 디버깅 기술. 유효성 검사기 다른 컴퓨터.

  • 누군가에게 이야기하십시오 . 그들이 도움을 줄 수 없거나 심지어 프로그래머조차 할 수없는 경우에도 때때로 이야기하면 아이디어 전구가 촉발됩니다

  • 재시작! 적절한 경우 컴퓨터, 서버 등을 다시 시작하십시오. 다른 것이 없으면 생각할 시간을 사용할 수 있습니다.

  • StackOverflow에 문의하십시오! 우리는 돕기 위해 여기 있습니다


1

언젠가는 효과가 있지만 때로는 같은 날에 알아 내야하기 때문에 가장 인기있는 답변을 좋아하지 않았습니다.이 순서대로 권장하는 것은 다음과 같습니다.

  1. 그것이 당신에게만 일어나는 것이 아니라는 것을 확인하십시오. 이렇게하면 많은 시간을 절약 할 수 있습니다. 필요한 구성 요소를 제거하거나 환경을 변경했을 수 있으며 코드 어딘가에서 예외가 발생하고 있습니다. 그것이 당신에게만 일어나면 환경 비교 도구를 사용합니다. 최근에 Envy라는 소프트웨어에 대해 읽었습니다. 프리웨어는 아니지만 10 USD가 소요됩니다.

  2. 모두에게 일어나는가? 이제 코드에서 View History를 수행하고 직접 또는 간접적으로 오류를 발생했을 수있는 최근 변경 사항을 확인하십시오.

  3. 최근 변경 사항이 없습니까? 매우 구체적인 오류 (예외) 인 경우 '스택 오버 플로우'. 이제는 'google it'보다 나쁘지 않지만 프로그래밍 연구를 위해 Google보다 먼저 스택 오버 플로우를 검색한다고 말하는 것이 좋습니다. 실제로 알려진 문제라면 여기에서 해결책을 찾을 가능성이 큽니다. 그렇지 않은 경우 관련 스택 교환 사이트에 질문을 게시하십시오. 매우 빠른 답변을 얻을 수도 있고, 그렇지 않은 경우에도 더 많은 조사를하는 동안 질문이있을 수 있습니다. 이점입니다.

  4. 온라인에서 답변을 찾지 못했거나 일반적인 오류가 아닌 경우 단계별로 코드를 살펴보고 각 단계에서 얻은 결과가 예상 한 결과에 적합한 지 확인하십시오. 각 방법에서 시작하여 계층 솔루션에서 아래에서 위로 이동하십시오. (즉, 성능 문제를 해결하려면 레코드를 검색하는 코드로 시작하십시오. 첫 번째 단계가 문제인지 빨리 판단 할 수 있으면 UI에서 시작하는 것이 의미가 없습니다).

  5. 코드를 두 번 통과 한 후에도 여전히 잘못된 것을 찾지 못한 경우 누군가에게 전화하여 이야기하십시오. 이미 언급했듯이 큰 소리로 말하면 전구에 불이 들어올 수 있습니다. 플러스 페어 프로그래밍이 정말 유용합니다.

  6. 이 시점에서 가능하다면 잠시 동안 또는 하루 동안 멀리 걸어가십시오. 나는 어제“나는 어떻게 fck”라고 생각하고 잠에서 깨어 났지만“물론 물론”생각했다는 매우 트윗을 읽었습니다. 그렇습니다.

  7. 여전히 대답이 없다면, 작은 작업 / 방법 / 기능으로 리팩토링을 시도 할 수 있다고 감히 말할 것입니다. 헨리 포드 (Henry Ford)는 '작은 과제로 나눌 수없는 복잡한 과제는 없다'고 말했다. 이 시점에서 솔루션이 너무 복잡하고 혼자서 또는 다른 사람의 도움으로 파악하지 못한 경우 코드를 더 작은 작업으로 리팩터링하십시오. 커밋하지 않아도 이유를 찾는 데 도움이 될 수 있습니다.

  8. 코드에 계측을 추가하십시오.

  9. 그것에 대해 트윗 ??


1

물러서야합니다. 내 모토는 '문제가 너무 어렵다면 잘못된 문제를 해결하는 것입니다.'입니다. 당신의 가정은 무엇입니까? 아무것도 믿지 마십시오.

그에 대한 추론은 '문제가 더 이상할수록, 해결책이 더 이상하다'입니다. 컴퓨터의 강점은 논리이기 때문에 논리에서 이길 수 없습니다. 당신은 두뇌가 있고 그것을 생각해야합니다.

현대에는 방화벽, AV, 안티 스파이웨어, 매일 밤 자동 업데이트 등 시스템에서 상호 작용하는 다른 많은 것들이 이동 목표를 처리해야합니다.


따라서 '문제가 더 이상할수록 해결책이 더 이상해집니다'
Adel

-1

구글 그것. 그것을 오버플로하십시오. 포럼에 게시하십시오. 기본적으로 혼자서 해결할 수 없다면 사람들에게 도움을 요청하십시오.


-1
  1. 문제를 기록하십시오.
  2. 열심히 생각하십시오.
  3. 솔루션을 구현하십시오.

간결하고 아주 좋습니다!
Adel

1
사실은 아닙니다. 같은 트랙을 따라 너무 열심히 생각하는 것은 당신이 할 수있는 최악의 일입니다. '각각의 가정을 체계적인 방법으로 도전, 열거, 재 방문 및 테스트하십시오' 는 해결책입니다. 사람들은 그것을 달성하는 다른 전술을 논의하고 있습니다.
smci
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.