코드의 버그 수정에 대한 특별 주석을 사용하십니까?

Question

내 동료 중 일부는 버그 수정에 특별한 의견을 사용합니다.

// 2008-09-23 John Doe - bug 12345
// <short description>

이게 말이 되요?
특별한 방식으로 버그 수정 사항에 대해 의견을 제시합니까?

알려주세요.

Answer 1

나는 그런 주석을 넣지 않습니다. 소스 제어 시스템은 이미 그 역사를 유지하고 있으며 이미 파일의 기록을 기록 할 수 있습니다.

그래도 무성한 일이 왜 이루어지는 지 설명하는 의견을 제시합니다. 따라서 버그 수정으로 코드를 예측하기 쉽고 명확하게 만들면 그 이유를 설명합니다.

Answer 2

시간이 지남에 따라 이것들은 축적되어 혼란을 더할 수 있습니다. 코드를 명확하게하고 명확하지 않은 관련 GOTCHA에 대한 주석을 추가하고 추적 시스템과 저장소에서 버그를 자세히 유지하는 것이 좋습니다.

Answer 3

최신 정보를 유지하기가 어려울 수 있기 때문에 실제 소스에서 언급하지 않는 경향이 있습니다. 그러나 소스 제어 로그 및 이슈 트래커에 링크 주석을 넣습니다. 예를 들어 Perforce에서 이런 일을 할 수 있습니다.

XYZ 대화 상자의 [Bug-ID] 문제. 크기 크기 코드를 ABC로 옮겼으며 이제 나중에 초기화했습니다.

그런 다음 내 문제 추적기에서 다음과 같은 작업을 수행합니다.

Changelist 1234에서 고정.

크기 크기 코드를 ABC로 옮겼으며 이제 나중에 초기화했습니다.

그렇다면 좋은 역사적인 마커가 남아 있기 때문입니다. 또한 특정 코드 라인이 특정 방식 인 이유를 알고 싶다면 파일 기록을 볼 수 있습니다. 코드 라인을 찾은 후에는 코드 주석을 읽고 어떤 버그가 있었는지, 어떻게 고정했는지를 명확하게 볼 수 있습니다.

Answer 4

솔루션이 특히 영리하거나 이해하기 어려운 경우에만.

Answer 5

나는 보통 내 이름, 이메일 주소 및 날짜와 내가 변경 한 내용에 대한 간단한 설명과 함께 날짜를 추가합니다. 컨설턴트로서 종종 다른 사람들의 코드를 수정하기 때문입니다.

// Glenn F. Henriksen (<email@company.no) - 2008-09-23
// <Short description>

그렇게하면 코드 소유자 또는 나를 따라 오는 사람들이 무슨 일이 있었는지 알아낼 수 있으며 필요한 경우 나와 연락 할 수 있습니다.

(예, 불행히도, 소스 제어가없는 경우가 많습니다 ... 내부 물건의 경우 TFS 추적을 사용합니다)

Answer 6

당시에는 좋은 생각처럼 보일지 모르지만 빠르게 손이 나옵니다. 이러한 정보는 소스 제어 시스템과 버그 추적기의 우수한 조합을 사용하여 더 잘 캡처 할 수 있습니다. 물론, 까다로운 일이 있다면 상황을 설명하는 의견은 어떤 경우에도 도움이되지만 날짜, 이름 또는 버그 번호는 아닙니다.

현재 직장에서 일하고있는 코드 기반은 20 세가되었으며 올해와 같은 많은 의견을 추가 한 것으로 보입니다. 다행히도 그들은 90 년대 후반에 모든 것을 CV로 변환 한 후 몇 년 동안 그 일을 중단했습니다. 그러나 이러한 의견은 코드 전체에서 여전히 흩어져 있으며 이제 정책은 "해당 코드에서 직접 작업하는 경우 제거하지만 그렇지 않으면 남겨 두는 경우"입니다. 동일한 코드가 추가되어 여러 번 제거되면 특히 따르기가 종종 어려워집니다 (예, 발생합니다). 또한 날짜가 포함되어 있지 않지만 날짜를 찾기 위해 구식 시스템에서 찾아야하는 버그 번호가 포함되어 있으므로 아무도하지 않습니다.

Answer 7

이와 같은 의견은 전복이 모든 커밋에 로그 항목을 입력 할 수있는 이유입니다. 그것이 코드가 아닌이 물건을 넣어야하는 곳입니다.

Answer 8

버그 수정에 간단하지 않은 것이 포함되면, 버그 픽스에 긴 설명이 필요한 경우에 종종 수정이 잘 설계되지 않았다는 신호로 받아들입니다. 때때로 나는 변경할 수없는 공개 인터페이스를 해결해야하므로 이것은 예를 들어 이러한 종류의 주석의 출처가되는 경향이 있습니다.

// <date> [my name] - Bug xxxxx happens when the foo parameter is null, but
// some customers want the behavior.  Jump through some hoops to find a default value.

다른 경우 소스 제어 커밋 메시지는 변경에 주석을 달기 위해 사용하는 것입니다.

Answer 9

직장에서 코드 내부의 버그에 대한 의견을 보는 경향이 있지만 개인 선호도는 코드 커밋을 하나의 버그에 연결하는 것입니다. 내가 하나를 말할 때 나는 정말로 하나의 버그를 의미합니다. 그 후에는 항상 변경 사항을 살펴보고 어떤 버그를 적용했는지 알 수 있습니다.

Answer 10

이러한 주석 스타일은 개발자 (예 : 모든 곳)에 걸쳐 다양한 기술 및 / 또는 비즈니스 지식이있는 다중 개발자 환경에서 매우 가치가 있습니다.

숙련 된 지식이 많은 개발자에게는 변화의 이유가 분명 할 수 있지만, 새로운 개발자에게는 의견을 두 번 생각하고 더 많은 조사를 수행 할 것입니다. 또한 시스템의 작동 방식에 대해 더 많이 배우는 데 도움이됩니다.

아, 그리고 "나는 그냥 소스 제어 시스템에 넣는 것"에 대한 경험에 대한 메모 : 다음과 같습니다.

소스에 있지 않으면 발생하지 않았습니다.

소스 제어 소프트웨어, 부적절한 분기 모델 등의 경험이 없기 때문에 프로젝트 소스 이력이 손실 된 횟수를 계산할 수 없습니다. 손실 될 수 없습니다 - 그리고 그것은 소스 파일에 있습니다.

나는 보통 그것을 먼저 거기에 넣은 다음 체크인 할 때 같은 주석을 붙여 넣습니다.

Answer 11

아니, 나는하지 않고, 나는 그 쓰레기와 같은 낙서를하는 것을 싫어한다. 버그 번호는 버전 제어 시스템에 대한 커밋 메시지와 스크립트에서 관련 커밋 메시지를 버그 추적 시스템으로 푸시하기 위해 추적 할 수 있습니다. 나는 그들이 소스 코드에 속한다고 믿지 않는다. 향후 편집은 단지 혼란 스러울 것이다.

Answer 12

원래 코드가 어떻게 생겼는지에 대한 맥락이나 원래 나쁜 행동에 대한 맥락이 없기 때문에 종종 그런 의견이 더 혼란 스럽습니다.

일반적으로 버그 수정이 이제 코드를 올바르게 실행하면 주석없이 남겨 두십시오. 올바른 코드에 주석 할 필요가 없습니다.

때로는 버그 수정으로 인해 상황이 이상하게 보이거나 버그 수정이 평범하지 않은 것을 테스트하고 있습니다. 그런 다음 주석을 갖는 것이 적절할 수 있습니다. 일반적으로 주석은 버그 데이터베이스에서 "버그 번호"를 다시 참조해야합니다. 예를 들어, "버그 123- 사용자가 640 x 480 화면 해상도에있을 때 홀수 동작을 설명하는"주석이있을 수 있습니다.

Answer 13

몇 년 동안 코드를 유지 한 후에 그런 주석을 추가하면 많은 버그 수정 주석이 있으면 코드를 읽을 수 없습니다.

그러나 당신이 옳은 모습을 바꾸는 것을 바꾸면 (그러나 미묘한 버그가있는) 더 복잡한 것으로 바꾸면, 당신이 한 일을 설명하는 짧은 의견을 추가하는 것이 좋습니다. (또는 그녀) 정당한 이유없이 당신이 과도하게 복잡한 것들을 생각합니다.

Answer 14

아닙니다. 나는 전복을 사용하고 항상 변화를 저지르기위한 동기에 대한 설명을 입력합니다. 나는 일반적으로 영어로 솔루션을 다시 작성하지 않고 대신 변경 사항을 요약합니다.

버그 수정이 만들어 졌을 때 코드에 주석을 넣는 여러 프로젝트에서 작업했습니다. 흥미롭게도, 우연히도 그렇지 않을 수도 있습니다.이 프로젝트는 어떤 종류의 소스 제어 도구를 사용하지 않았거나 경영진의 Fiat의 이러한 종류의 협약을 따를 의무화 된 프로젝트였습니다.

솔직히 말해서, 나는 대부분의 상황에서 이것을하는 데있어 가치를 실제로 보지 못합니다. 무엇이 바뀌 었는지 알고 싶다면 Subversion Log와 Diff를 살펴 보겠습니다.

내 두 센트.

Answer 15

코드가 수정되면 주석은 쓸모없고 아무도 흥미롭지 않습니다.

버그가 해결되지 않으면 주석이 잘못되었습니다. 그러면 의미가 있습니다. :) 그러니 버그를 실제로 해결하지 못했다면 그러한 의견을 남겨주세요.

Answer 16

우리가 사용하는 특정 의견을 찾으려면 DKBUGBUG - David Kelley의 수정 및 검토자가 쉽게 정체 될 수 있음을 의미합니다. 물론 날짜 및 기타 VSTS 버그 추적 번호 등을 추가 할 것입니다.

Answer 17

VC가 귀하를 위해 유지할 메타 데이터를 복제하지 마십시오. 날짜와 이름은 VC에 의해 자동으로 추가되어야합니다. 변경 사항을 요청한 티켓 번호, 관리자/사용자 이름 등은 코드가 아닌 VCS 댓글에 있어야합니다.

이것보다는 :

// $ DATE $ NAME $ 티켓 // 다음 가난한 영혼에 유용한 댓글

나는 이것을 할 것이다 :

// 다음 가난한 영혼에 유용한 의견

Answer 18

코드가 라이브 플랫폼에있는 경우 소스 컨트롤 저장소에 직접 액세스하지 못하는 경우 라이브 시스템의 버그 수정의 일부로 작성된 변경 사항을 강조하기 위해 주석을 추가합니다.

그렇지 않으면 체크인시 입력 한 메시지에는 필요한 모든 정보가 포함되어 있지 않습니다.

건배,

롭

Answer 19

타사 라이브러리/구성 요소에서 버그 수정/향상을 만들 때 종종 의견을 제시합니다. 이를 통해 최신 버전의 라이브러리/구성 요소를 사용해야하는 경우 변경 사항을 쉽게 찾아서 이동할 수 있습니다.

내 자신의 코드에서는 버그 픽스를 거의 언급하지 않습니다.

Answer 20

나는 다원 프로젝트에서 일하지 않지만 때로는 단위 테스트에 특정 버그에 대한 의견을 추가합니다.

버그와 같은 것은 없으며 테스트가 충분하지 않습니다.

Answer 21

가능한 한 많은 TDD를 수행하기 때문에 (다른 모든 방법은 다른 모든 방법으로 인해 끝없는 시간을 일하도록 강요 할 것이기 때문에) 버그를 거의 해결하지 못합니다.

대부분의 경우 코드에 이와 같은 특별한 비고를 추가합니다.

// I KNOW this may look strange to you, but I have to use
// this special implementation here - if you don't understand that,
// maybe you are the wrong person for the job.

거칠게 들리지만 자신을 "개발자"라고 부르는 대부분의 사람들은 다른 말을받을 자격이 없습니다.