발견하고 패치 한 버그를 기록해야합니까?

나는 이것이 일반적인 상황이라고 가정합니다 : 나는 코드를 테스트하고, 버그를 발견하고, 수정하고 버그 수정을 저장소에 커밋합니다. 많은 사람들이이 프로젝트를 수행한다고 가정 할 때, 먼저 버그 보고서를 작성하여 자신에게 할당 한 다음 커밋 메시지에서이를 참조해야합니다 (예 : "Fix bug #XYZ. 버그는 X와 Y로 인한 것입니다. Q와 R ")? 또는 버그 보고서를 건너 뛰고 "B가 발생했을 때 A를 발생시킨 버그 수정. 버그는 X와 Y로 인한 문제입니다. Q와 R로 수정했습니다."와 같은 메시지가 표시됩니다.

더 나은 방법은 무엇입니까?

버그 보고서의 대상이 누구인지에 따라 다릅니다.

개발자가 내부적으로 만 살펴보고 수정해야 할 사항을 알고 있다면 귀찮게하지 마십시오. 그 시점에서 그것은 단지 소음입니다.

어쨌든 기록해야 할 이유는 다음과 같습니다.

• 릴리스 정보에는 수정 된 버그 (이 버그가 충족하는 임계 값까지)에 대한 정보가 포함되어 있습니다. 특히이 버그에 노출 된 취약점이있는 경우
• 경영진은 "버그 수정 시간"/ "버그 수 감지"등의 개념을 원합니다.
• 고객은 버그 추적기의 현재 상태를 확인할 수 있습니다 (문제가 알려진 것인지 등).
• 테스터는 테스트해야 할 변경 사항에 대한 정보를 얻습니다.

나는 당신의 제품이 버그로 출시되었는지 아닌지에 달려있다.

발견 한 버그와 함께 릴리스 된 경우 예, 버그 보고서를 작성하십시오. 릴리스주기가 길어질 수 있으며 이미 수정 한 동안 버그가 새로운 문제로보고되는 것을 원하지 않습니다.

버그가 아직 배송되지 않은 경우 동일한 경로를 따르지 않습니다. 버그가 아직 릴리스되지 않았기 때문에 버그를 재생성하려는 사람들에게 시간을 낭비하게 할 것입니다.

고객이보고 한 버그 인 경우이 작업을 수행해야합니다. 최악의 경우 : 버그를 고치지 만 아무도 모른다. 고객이 버그를보고합니다. 동료가 버그를 수정하려고 시도하지만 이미 수정했기 때문에 버그를 재현 할 수 없습니다. 그렇기 때문에 버그 기록을 원합니다.

코드 검토를 수행하는 경우에도 유용합니다. 일반적으로 코드는 일부 작업에 대해 작성된 후 검토됩니다. 이 경우 버그 수정을 격리하는 것이 좋습니다. 작업 목록에 무언가를 넣은 다음 모든 작업을 수행해야 할 수도 있습니다.

이것은 몇 가지 요인에 따라 다릅니다.

Pieter B와 Caleth는 모두 답변에 다음을 나열합니다.

• 버그가 공식 릴리스의 일부입니까?
• 버그 / 시간이 구체적으로 추적 되었습니까?

종종 인증 요구 사항에 따라 내부 절차를 따를 수도 있습니다. 특정 인증서의 경우 코드의 모든 변경 사항을 이슈 트래커의 레코드로 추적 할 수 있어야합니다.

또한 때로는 사소하게 보이는 버그 수정조차 처음 나타나는 것처럼 사소하고 결백하지 않습니다. 관련이없는 문제를 전달하기 위해 이러한 버그 수정을 자동으로 번들로 묶고 나중에 버그 수정에 문제가있는 경우 격리하거나 되돌릴뿐 아니라 추적하기가 훨씬 더 어려워집니다.

이 질문은 프로젝트 책임자 또는 "티켓팅 프로세스"담당자를 통해서만 가능합니다.

그러나 다른 방법으로 물어 보자. 왜 패치 한 버그를 기록 하지 않겠습니까?

내가 볼 수있는 유일무이 한 이유는 버그 보고서를 제출하고,이를 저지하고, 종결하려는 노력이 버그를 수정하는 시간보다 수십 배나 크기 때문입니다.

이 경우 문제는 버그를 쉽게 수정하는 것이 아니라 서류 작업이 너무 오래 걸린다는 것입니다. 정말 안됩니다. 나를 위해 Jira 티켓을 만드는 오버 헤드는을 누른 c다음 짧은 한 줄 요약을 입력 하고을 누릅니다 Enter. 설명은 이슈 번호와 함께 커밋 메시지로 잘라 붙여 넣을 수 있으므로 오버 헤드조차도 아닙니다. 마지막에 . c <Enter>문제가 해결되었습니다. 5 번의 키 누름 오버 헤드가 발생합니다.

나는 당신에 대해 모르지만, 작은 버그 조차도 이런 식으로 모든 버그 수정 을 기록하는 정책으로 만들기에는 충분하지 않습니다 .

Jira와 같은 티켓 시스템으로 쉽게 작업 할 수 있지만 소스 코드로는 작업 할 수없는 사람들이 꽤 많습니다. 티켓 시스템에서 생성 된 보고서도 있지만 소스에서는 생성되지 않습니다. 프로세스 문제 나 기타 문제에 대한 통찰력을 제공 할 수있는 작은 1- 라인 버그 수정의 꾸준한 증가와 같은 가능한 개발에 대해 배우고 자하는 버그 수정을 확실히 원합니다. 예를 들어 왜 작은 버그 수정을 자주해야합니까 (자주 발생한다고 가정)? 테스트가 충분하지 않을 수 있습니까? 버그 수정이 도메인 변경입니까, 아니면 코드 오류입니까? 기타.

내가 따르는 규칙은 작업중 인 섹션이 아직 릴리스되지 않았고 아직 실행되지 않고 사용자가 본 적이 없다면 모든 작은 버그를 수정하고 계속 진행한다는 것입니다. 소프트웨어가 출시되어 프로덕션 환경에 있고 일부 사용자가 본 소프트웨어는 일단 버그 보고서를보고 검토합니다.

버그라고 생각하는 것이 다른 사람을위한 기능이라는 것을 알았습니다. 이러한 버그를 검토하지 않고 버그를 수정함으로써 버그를 수정하는 대신 버그를 생성 할 수 있습니다. 버그를 수정하기 위해 어떤 라인을 변경하고 버그를 수정해야하는지 계획을 버그 보고서에 입력하십시오.

요약 : 이 모듈이 생산 된 적이 없다면 신속하게 보이는 모든 버그를 수정하고 사양을 따르십시오. 모듈이 이미 생산중인 경우 수정하기 전에 검토 할 모든 버그를 버그 보고서로보고하십시오.

예 .

버그 보고서를 작성할 가치가있는 상황을 드러내는 답변이 이미 있습니다. 몇 가지 답변. 그리고 그들은 다릅니다.

유일한 대답은 아무도 모른다는 것입니다. 다른 시간에 다른 사람들 은 그 문제에 대해 다른 의견을 가질 것입니다.

이제 버그가 발생하면 두 가지 해결책이 있습니다.

• 버그 보고서를 열만 한 가치가 있는지 아닌지, 동료의 의견을 물을지 여부를 숙고 한 다음 나중에 누군가가 그것에 대해 질문했기 때문에하지 않은 것을 후회하고 이미 보고서를 가지고 있다면 그냥 가리켜
• 그냥 보고서를 작성하십시오

보고서 작성이 더 빠르며 그렇지 않은 경우 ... 자동화하십시오.

자동화하는 방법? 트래커가 스크립팅을 지원한다고 가정하면, 호출 할 수 있고 커밋 메시지 (제목 및 본문)를 사용하여 버그 보고서를 제출하고 추적과 ​​관련된 커밋 개정과 함께 즉시 "구현 된"것으로 닫을 스크립트를 작성하십시오.

나는 다른 답변이 모두 좋은 경험의 규칙을 제공 하고이 시점에서 몇 가지를 만지는 것에 동의 할 것이지만, 나는 정말로 확실한 답변 만 있다고 생각합니다.

관리자에게 문의하십시오 . 그룹이 어떻게 구성되어 있는지에 따라 관리자 또는 대안으로 리드 또는 스크럼 마스터 등을 계획하십시오.

좋은 연습과 나쁜 연습에 대한 여러 가지 시스템이 있지만 팀에 올바른 일을하고 있다는 것을 아는 유일한 방법은 물어 보는 것입니다.

1 분의 회랑 대화를 따라 뭔가 할 것 : "이봐 (보스), 몇 분 밖에 걸리지 않는 사소한 버그를 고치면 티켓을 만들 가치가 있습니까? 아니면 커밋 메시지에서 언급해야합니까? " 그리고 당신은 확실히 알게 될 것입니다. 그 방법이 당신의 팀과 매니저를 성가 시게하면 세상의 모든 좋은 관행은 쓸모가 없습니다.