자료 수집

  • 문제를 분석한느 과정에서 도움이 된다고 생각하는 질문만 골라 최소로 물어봐야한다.
    • 질문을 많이 할수록 점점 더 대답은 줄어든다.
  • 충돌을 보고 하는 과정에서 익명성과 사생활 보호를 강조하는 정책이 중요하다.
  • 자동으로 수집한 자료가 개발자가 충돌 원인을 밝히는 데 도움이 될 수 있는지 고민해야된다.
    • 제품의 정확한 버전
    • 운영체제 버전과 인터넷 익스플로러 버전
    • 충돌이 발생한 코드 파일명과 행 번호
    • 문자열로 표현하는 오류 메시지
    • 오류 종류를 위한 고유한 숫자 코드
    • 어떤 작업을 하고 있었는지에 대한 사용자 설명
    • 사용자 이메일 주소
  • 정보를 최소한으로 수집해야된다.
    • 충돌보고 공정을 매우 빠르게 진행해서 사용자가 조바심을 내지 않게 한다.

회사로 전화걸기

  • 표준 HTTP 요청으로 보내면, 고객이 특정 방화벽 내에 있더라도 이를 통과해서 버그 보고서를 발송할 수 있다.
  • 지연 전송(delayed transmission): 충돌 보고설르 즉시 보내지 않고 파일이나 레지스트리에 보고서를 기록한 다음에, 사용자가 응용프로그램을 다시 띄우는 시점에 이를 발송하는 기법
    • 보고서 수집시간을 조금 지연시키지만, 충돌 상태가 나빠서 응용프로그램이 너무나도 심각한 타격을 입었기에 버그 보고서를 전송할 수 없는 상황이라도 여전히 다음 기회를 노려 보고서를 받을 수 있다.

중복 충돌 식별하기

  • 충돌 자료의 핵심원인을 포함하는 유일한 문자열을 만들어서 해결했다.
  • Error 91(global:IsRoot:0) V1.0.32
    • 1.0: 버전
    • 32: 빌드 번호
    • global: 파일 이름
    • IsRoot: 함수 이름
    • 0: 행 번호
    • 91: 오류 번호
  • 특정 문제를 위해 쉽게 검색할 수 있도록 제목을 만들었다.
    • 파일이름:함수:행번호
  • 흔히 볼 수 있는 중복 보고 원인 중 하나는, 충돌을 처리하는 코드 자체에서 발생하는 충돌이다.

디버깅

  • 모든 충돌 보고서를 살펴볼 시간이 없는 경우, 몇 달을 기다려서 어떤 충돌이 가장 일반적인지 살핀 다음에, 가장 자주 발생하는 충돌만 해결하려고 노력해야 한다.

선별

  • 어떤 버그를 무시하며 어떤 버그는 가장 시급하게 수정할지 결정하는 좋은 선별 기술은 중요하다.
    • 사용자에게 하드웨어 결함이 있다.
    • 사용자가 우리 파일을 수동으로 편집한 경험이 있다.
    • 사용자가 충돌을 이끄는 원인인 낡은 운영체제를 쓰고 있다.
    • 사용자는 아주 낮은 메모리 환경에서 우리 프로그램을 운영하고 있다.
  • 나에게는 충돌이 한 번만 일어난 경우는 거들떠보지도 않는 원칙이 있다.

충돌 보고는 당신에게 꼭 필요합니까?

  • 사내용 소프트웨어를 염두에 두고 기업용 소프트웨어를 개발하고 있다면, 아마도 자동화된 충돌 보고는 별로 쓰로 없을 것이다.
    • 기업용 소프트웨어는 일반적으로 특정 문제를 해결하기 위해 쓰여지며, 상품 소프트웨어와 비교해서 상당히 비싸다.
  • 상품이나 소비자용 소프트에ㅜ어를 개발하고 있다면, 품질은 글자 그대로 경쟁력을 제공하는 원천이다.