패치 노트에 버그 ID를 인용하는 것이 나쁜 습관으로 간주 될 수있는 이유는 무엇입니까?

Bug reopen vs. new 의 주석 및 후속 upvotes를 기반으로 합니다 .

패치 노트에 버그 ID를 인용하는 것은 매우 우호적입니다. – 크레프

적어도 일부 사람들은 패치 노트에서 버그 ID를 참조하는 것이 좋지 않다고 생각합니다. 나는 상당히 경험이 부족한 개발자이므로 왜 그런지 궁금합니다.

제 생각에는 사용자가 버그 데이터베이스에 대한 읽기 권한을 가지고 있다고 가정하는 것이 좋습니다. 사람들이 업그레이드시기를 결정하기 위해 특정 버그가 수정되기를 기다리는 경우가 많습니다.

눈에 띄는 점은 버그 ID 만 인용하는 것 뿐입니다 . 또한 버그 추적기로 이동하지 않고도 항상 이해할 수있는 설명을 제공해야합니다. 또한 이전 릴리스 노트를 완전히 무효화하지 않고도 향후 버그 추적기를 전환 할 수 있습니다.

인용 된 의견에서 말했듯이 ... 비우호적입니다.

비우호적

다음 시나리오를 상상해보십시오. 소스 제어에서 로그를보고 있습니다. 커밋이 어떻게 바뀌 었는지 궁금합니다. 일반 영어로 설명하는 대신 다음과 같이 알려줍니다.

해결 된 # 1307

도움이 되길 바라면서 버그 추적 시스템을 실행합니다. 버그 # 1307이 해결 된 것으로보고되었습니다. 설명에서 다음을 볼 수 있습니다.

# 1284와 동일한 버그

감사합니다. 매우 도움이되었습니다. 이제 버그 보고서 # 1284로 이동하여 버그 # 1112, # 1065 및 # 1067을 나타내는 버그 # 1113의 복제본임을 읽으십시오.

5 분 후에 처음에 무엇을 검색하고 있는지 모릅니다.

훨씬 더 도움이 버전 제어 로그 메시지는 다음과 같습니다

웹 사이트 자체에서 사용되는 것과 동일한 암호 길이 정책을 데이터 액세스 계층에 적용하여 사용자가 25 자보다 긴 암호로 로그온 할 수없는 문제를 해결했습니다 (# 1307 참조).

같은 방식으로 버그 추적 시스템에서 리포트 # 1307은 버그 리포트 # 1284가 무엇인지, 그리고 새로운 리포트와 이전 리포트가 어떻게 다른지 회상 하여 보다 자명 할 수 있습니다 .

고객과 비우호적

이것이 유일한 친근감 문제는 아닙니다.

두 번째는 추가 정보없이 너무 많이 참조하면 패치 노트 / 버전 제어 로그 / 버그 추적 시스템 보고서 를 해당 시스템에 익숙하지 않은 사람이 사용할 수 없게 만드는 것입니다 . 매일 버그 추적 시스템을 처리 할 때 보고서를 빠르게 탐색하고 여러 보고서를 나란히 보는 방법 등을 알고 있습니다. 기술적 배경이없는 고객은 쉽게 길을 잃을 수 있습니다.

여기서도 더 자세한 메시지는 참조보다 매우 유용합니다. 여전히 참조를 유지하고 싶다는 점에 유의하십시오. 2 주 전에 발생한 버그와 동일하지만 ID를 기억하지 않는 버그보다 더 잘못된 것은 없습니다.

참고로, 많은 관할권에서 동일한 문제가 존재합니다. 예를 들어 프랑스에서는 법이 여러 출처를 언급하는 것은 드문 일이 아니며 그 동안 변경 될 수 있습니다. 이것은 그것을 완전히 이해하기 위해 때때로 도서관에서 몇 시간을 보내면서 수십 개의 참조 텍스트를 검색해야하며, 각 텍스트는 다른 텍스트에 대한 자체 참조를 갖습니다.

사용자가 인용 된 문제를 읽을 수 있다면 패치 노트에 문제 번호를 인용해도 아무 문제가 없습니다. 버그 데이터베이스를 통해 누구나 읽을 수 있다면 버그 번호를 인용하는 것이 매우 유용 할 수 있습니다. 패치 노트가 링크를 허용하는 형식 인 경우 문제 ID를 해당 문제에 대한 링크로 만들 수 있습니다. 이것이 모든 문제를 일반 대중에게 공개해야한다는 의미는 아닙니다. 가려져있는 암호를 사용하는 것이 여전히 유용 할 수 있습니다 (예 : 암호가있는 위치).

읽는 사람이 갈 수없는 버그 번호를 인용하고 버그의 세부 사항과 기록을 조회하면 매우 우호적입니다. 이슈 ID없이 그러한 이슈를 인용하는 것이 훨씬 친숙하지는 않습니다.

패치 노트를 읽을 사람과 소프트웨어의 대상 사용자가 누구인지에 따라 다릅니다.

그러나 대부분의 경우 대부분의 사용자 는 버그 ID가 무엇인지 신경 쓰지 않습니다 . 그들은 왜 그것이 깨 졌는지, 픽스가 무엇인지, 또는 다른 것을 신경 쓰지 않습니다. 그들은 각 변경에 대해 다른 페이지로 이동하지 않고도 매우 간결한 텍스트 설명으로 변경된 것을 알고 싶어합니다.

버그 ID를 인용하면 저를 멈추게하고 생각하게되며, 저는 사용자로서 생각하고 싶지 않습니다. 일종의 사용성 문제입니다.

Visual Assist X 의 변경 로그를 살펴보십시오 . 연결된 모든 버그 ID는 변경 사항을 이해하지 못하게하는 소음입니다. 그리고 이것은 프로그래머를 대상으로하는 Visual Studio 용 애드온입니다. 저는 프로그래머입니다. 이것이 나를 귀찮게한다면 버그 추적기가 무엇인지조차 모르는 일반 사용자를 상상해보십시오.

추신 : 나는 질문을 촉발시킨 의견의 저자였습니다.

버그 ID는 의무적으로 A에 대한 기준의 포인트 . 그 원인:

• 모호함 방지 : 둘 이상의 버그에 대한 설명이 비슷할 수 있습니다. 그래서 그것들을 구별하기 위해 앵커가 필요합니다.
• 편리 성 : 고객과 내부적으로 또는 내부적으로 버그를 논의 할 때 종종 버그 ID가 짧은 형식으로 사용됩니다. 패치 노트에서 ID를 생략하면 이에 대해 논의하기가 어렵습니다.

3052는 이미 수정되어 여전히 3077로 작업 중입니다.

보다 편리합니다 :

"적용 사용자 클릭시 NullReferenceException"에서 계속 작동하는 "적용 버튼에서 응용 프로그램 충돌"이 수정되었습니다.

나는 그것이 당신의 시스템에 달려 있다고 말하고 싶습니다 : 내가 사용 하는 것이 커밋 메시지에서 그러한 참조를 자동으로 감지 하고 버그 추적기에 저장된 티켓 에 대한 링크를 추가하는 것은 운이 좋으므로 문제가되지 않습니다.

그러나 내가 사용할 수없는 시스템에 있었다면 버그 ID 에 대한 간단한 설명과 함께 티켓 ID (티켓 ID로 로그를 빠르게 검색 할 수있는 방법)에 대해 언급하고 있습니다 .