사소한 수정을 기록해야합니까?

저는 코드 상점 2에 있습니다. 그리고 프로그래머의 수가 1 이상인 경우 버그 추적기가 유용하다는 것을 알고 있지만 버그, 변경 및 수정을 로깅하는 것이 사소한 시간에 가치가 있다고 확신하지는 않습니다. 간단한 버그를 발견하면 이해하고 수정 한 다음 테스트를 통해 실행합니다. 그런 다음 로그를 기록해야한다는 것을 깨달았습니다.

이론적으로 버그 로깅은 버그 찾기와 버그 수정 사이에서 수행되어야하지만 버그를 수정하는 것보다 빠르면 드래그처럼 보입니다. 더 큰 코드 상점에서, 보스는 누가 무엇을하고 있는지에주의를 기울이고 다른 사람들이 어디에서 m을하는지 아는 것이 좋습니다.

나는 이미 고쳐 놓은 것을 설명하고 즉시 닫습니다. 나는 누군가 가이 닫힌 버그를 다시 볼 것이라고 의심합니다. 공정 지방을 다듬을 때입니까?

시스템에 대한 모든 변경 사항을 기록해야합니다. 버그 보고서를 변경 번호에 연결하는 한 이벤트 후 로그에 아무런 문제가 없습니다.

그런 다음 문제가 발생하면 버그를 추적 하여 변경 한 이유 를 찾을 수 있습니다.

대부분의 경우에 당신은 옳고 아무도 이것들을 다시는 보지 않을 것입니다. 그러나 문제가 발생했을 때 100 개 중 1 개에서이 정보는 매우 귀중합니다.

최신 정보

분명히 새로운 기능을 개발하고 있고 기능의 일부에서 버그를 발견 한 경우 별도의 변경 사항으로 기록 할 필요는 없습니다. 이 경우 주요 기능을 요청하는 항목에 대해 기록합니다.

기능과 시스템이 품질이나 고객에 전달되면, 그 다음 은 내가 위에서 설명한 것을 할 필요가있다.

소스 제어 도구를 사용하는 경우 커밋 설명에서 수정 한 버그를 설명 할 수 있으며 일반적으로 아주 작은 버그 수정에 충분한 문서입니다.

또한 FogBugz 및 Kiln 과 같이 소스 컨트롤 및 리포지토리와 완전히 통합 된 버그 / 기능 추적기 를 사용하는 경우 전역 검색 도구를 사용하여 이러한 버그 수정을 찾고 코드 변경 내용을 확인할 수 있습니다. 용이하게.

또한 프로그래밍 파트너에게 코드 검토를 할당하여 사소한 수정 사항을 검토 할 수는 있지만 난 실패합니다.

메트릭스 관점에서 여전히 유용 할 수 있습니다.

이 정보는 사장에게 여러 가지를 보여주기 위해 사용될 수 있습니다.

• 우리는 더 많은 개발자가 필요합니다
• 프로세스의 다른 부분이 깨졌습니다 (왜 그렇게 많은 버그가 있습니까? 다른 사람이 대부분의 버그를 생성합니까). 아마도 너무 많은 버그가 있음을 보여줍니다. 어쩌면 이것을 일으키는 원인이 있습니까? 당신은 너무 일찍 발표하고 있습니까? 충분한 테스트가 완료 되었습니까?
• 당신이 작업 한 것들에 대한 좋은 목록은 보너스 시간입니다.

그것은 모두 당신이 말하는 버그의 크기에 달려 있습니다. 새 코드를 추가하는 동안 발견 한 라이너는 예를 들어 무의미합니다.

크기에 관계없이 모든 변경 사항을 기록하려고합니다. 자신이나 다른 사람 (미래 또는 현재)이 언제 돌아가서 그 변화가 다른 원인의 원인인지 알아볼 필요가 없습니다.

추적은 중요하지만 검토 할시기가되면 다른 시나리오도 고려하십시오. 버그 추적기에서 보고서를 가져 오는 상사를 통해 공식적으로 직접 또는 비공식적으로 발생합니다.

숫자를 높이는 '김지'를 고려하십시오. 결국, 그것들은 당신이 고 쳤던 버그이며, 사소한 수정이라도 버그를 고쳐야합니다.

그들을 기록하십시오.

이것에 대한 답은 실제로 당신이 어디에 있는지에 달려 있습니다.

이는 새로운 프로젝트 또는 설계중인 새로운 기능 세트에 적용될 수 있습니다.

초기 설계 초기 설계 중에 생성 한 코드에서 버그를 발견하면 버그 트랙을 만들 필요가 없습니다. 나중에 문제를 발견하면 쉽게 풀 수 있도록 변경에 대한 별도의 커밋을 제안합니다.

테스팅

코드는 일반적으로 단위 테스트 중에 여전히 성숙하지 못하므로 다른 그룹에서 수행하지 않는 한 아니오라고 말합니다. 버그 추적기와 다른 그룹에서 단위 테스트를 수행하는 경우 테스트 절차를 공식화하는 좋은 방법입니다.

CSCI 테스트는 다릅니다. 다른 그룹에서 이루어 졌습니까? 그렇다면 그렇습니다 (위 참조). 이것이 릴리스 전 테스트의 마지막 단계입니까? 그렇다면이 시점에서 소프트웨어가 성숙한 것으로 간주되기 때문입니다. 메트릭에 관심이 있다면이 시점에서 버그 추적을 시작하는 것이 좋습니다.

더 높은 수준의 테스트를하려면 버그 추적을 사용해야합니다. 이 시점에서 소프트웨어는 성숙한 것으로 간주되어야하며 버그를 추적하는 것이 중요합니다.

해제

릴리스 된 코드에서 항상 버그를 추적해야합니다. 이것은 책임에 중요합니다.

필요에 맞게 프로세스를 간소화하는 것도 중요합니다. 거대한 버그 추적 시스템이 정말로 필요합니까? 모든 분야가 2 명으로 구성된 팀에게 정말로 중요한가?

외부에 공개 된 이전 버전의 소프트웨어에서 다른 사람이 버그를 겪을 가능성이 있습니까? 그렇다면 버그와 수정 사항을 모두 기록하면 유용 할 수 있습니다.

다른 사람들은 버그를 수정하는 것보다 버그를 기록하는 데 시간이 오래 걸리면 로깅 할 가치가 없다고 제안했습니다. 관련 시간 범위는 버그 찾기와 수정 사이가 아니라 버그가 도입 된 시간과 수정이 릴리스 된 시간 사이입니다.

변경 및 릴리스 기록에 버그가 현재의 순간을 보지 못했다고 표시되는 경우 소스 제어로 점검 할 때 수정 사항을 로깅하면 충분합니다.

이것은 이 질문에 거의 가깝지만 , 이것이 사소한 수정에 중점을두기 때문에 중복인지 확실하지 않습니다 .

Jon Arid Torresdal이 버그를 추적하지 않아야하는 이유 -대신 수정하십시오.

1. 개발 중 : 기능에 대한 버그가 발생했습니다. 빌드를 중단시키는 테스트 케이스 를 추가 한 후 기능에 대해 수정 사항을 체크인하십시오.

2. 릴리스 후 : 동작을 문서화하십시오 . 업데이트를 릴리스하려면 1로 이동하십시오. 해당 릴리스를 담당하지 않는 경우 test + fix를 개인 브랜치에 보관하십시오.

코드가 릴리스 된 후 다른 우선 순위가있을 수 있으며 버그를 수정하는 것이 쉽지는 않지만 지속적인 배포를 수행하지 않는 한 수정 배포는 저절로 경제적이지 않을 수 있습니다.

따라 다름 방법 , 나는이 법안을 사용 사소한 :

걸리는 경우 더 이상 그것을하는 데 걸린 것보다 로그 수정 을, 그것은 아닙니다 가치가 그것을 기록.