코드 내에서 버그 수정 주석을 유지하는 것이 좋습니까?

우리 팀은 클리어 케이스를 버전 관리로 사용하고 있습니다. 내가 일하고있는 프로젝트는 7-8 년 전에 시작되지 않았습니다. 프로젝트의 전체 수명 동안 버그 수정 서비스 팩 등을 여러 릴리스했습니다. 버그 추적 시스템을 사용하여 문제를 추적하고 버그 수정 작업을하는 대부분의 사람들은 START / 날짜, 작성자, 버그 ID 등이있는 END 블록

나는 이것이 매우 관련이 없으며 코드를 어수선하게 만들고 유지 관리하기 쉽지 않다고 생각합니다. 이것은 작업 주석의 추가 수명주기 정보를 유지할 수있는 체크인 주석 / 레이블 등의 일부 여야합니다.

따라야 할 가장 좋은 방법은 무엇입니까?

이 코드를 검토 한 사람들 중 일부는 버그를 수정하고 삶을 편하게 해 줄 것을 고집합니다. 내 이해에서 그들은 파일을보기에 매핑하여 파일을 검토하고 지점의 변경 로그를 가져 와서 검토해야합니다. 검토를 위해 업데이트 된 코드를 제출하는 모범 사례를 얻을 수 있다면 도움이 될 것입니다.

코드에 주석으로 버그 수정을 추가하는 문제는 전체 기사를 얻지 못한다는 것입니다. "이것은 버그 blah에 대한 수정"이라는 완벽하게 훌륭한 코드 조각을 보게되면 , 나의 첫 번째 반응은 "그래서 뭐?"라고 말하는 것입니다. 코드가 있으며 작동합니다. 코드를 유지 관리하기 위해 알아야 할 유일한 것은 코드의 기능을 알려주는 주석입니다.

더 좋은 방법은 SCM 커밋 로그에 버그 수정 참조를 추가하는 것입니다. 그러면 버그가 무엇인지, 버그가 어디에서 왔으며 어떻게 수정되었는지 알 수 있습니다. 또한 릴리스 시간이되면 SCM 로그를 추출하고 버그가 있음을 나타내는 글 머리 기호를 추가하면 수정 될 수 있습니다. 다른 브랜치 나 버전에서 동일한 버그가 발생하면 수정 프로그램을 쉽게 찾을 수 있으며 실제로 동일한 버그가 있으면 다시 적용 할 수 있습니다.

이 모든 것을 말하면서, 나는 또한 Charles의 대답에 동의합니다. 코드 조각에 대한 이유가 명확하지 않은 경우 반드시 관리자에게 코드가 이유가 있으므로주의해서 처리해야한다고 알립니다.

대부분 나쁜 연습입니다. 나는 절대로해서는 안된다고 말하지 않을 것입니다. 간혹 외부 API의 버그와 같은 문제가 발생하는 경우가 있습니다. 기본 버그에 대해 모르면 해결 방법이 완전히 죽어 보일 수 있습니다. 이 경우 코드에 버그를 문서화하는 것이 좋습니다. 따라서 동료 나 나중의 자아는 명백히 두뇌에 죽은 코드를 "수정"하려고하지 않습니다.

나쁜 연습. 주석이 오래되어 코드가 복잡해집니다. 필요한 경우 SCC 시스템의 버전 ​​기록에서 정보를 계속 사용할 수 있습니다.

나쁜 습관처럼 들립니다. 조직에서 다른 버그 추적 시스템으로 마이그레이션하기로 결정하면 어떻게됩니까? 제품을 현재 사용중인 도구에 너무 단단히 묶지 마십시오. 특정 버그 ID를 참조하는 대신 코드가 왜 그렇게 보이는지 명확하지 않은 이유는 코드의 주석으로 디자인 결정에 동기를 부여하는 것입니다.

내 첫 번째 반응은 스스로 반복하지 않으므로 코드에서 SCM 로그로 가져 오는 것입니다. 함수, 작성자 이름 및 파일 및 함수의 작성 날짜에 대한 개정 주석에 대해 비슷한 논의를했습니다. 과거 (SCM이 사용되기 전에)이 모든 정보는 파일의 진화를 재구성 할 수 있도록 파일에 보관되었습니다.

개발자의 약 절반은이 정보가 한 곳에서 모든 정보를 가질 수 있기를 원합니다 (이로 인해 SCM에서 변경 사항을 검색하도록 트리거 함). 개발자의 나머지 절반은 coe에서 변경된 사항에 대한 단서를 찾기 시작하지 않지만 SCM에서 코드에 정보가 필요하지 않습니다. 우리는 이러한 의견으로 무엇을해야할지 아직 결정하지 않았습니다. 그것은 사람들이 일하는 방식에 달려 있으며 일부 사람들은 알려진 방법을 떠나는 것에 매우 고집이 있습니다. 코드 블록을 주석 처리하고 코드에 영원히 남겨 두는 것과 똑같은 것입니다.

Dyaster et al. 에 추가하기 위해 . JIRA는 버그 수정과 관련된 변경 사항을 표시 할 수있는 훌륭한 기능을 가지고 있지만 버그 수정 을 문서화하는 가장 좋은 방법 은 테스트 케이스입니다. 수정 된 버그를 나타내는 주석없이 코드가 명확하지 않으면 "코드 냄새"입니다. 즉, 냄새를 정리할 시간이 없다면 주석은 테스트 사례를 참조해야하며, 코드가 왜 그 일을하고 있는지 훨씬 더 분명해야합니다. 버그 수정을 설명하는 테스트 사례를 작성할 시간이 없다면 버그가 아직 수정되지 않았으며 연기 된 것입니다.

코드 자체가 아닌 커밋 메시지에 버그 수정 ID를 추가하는 것에 동의합니다. 버그 ID에 대한 커밋 메시지를 자동으로 스크랩하는 버그 추적기는 매우 유용합니다.

또한 버전 제어 시스템 의 blame / annotate / praise 명령을 사용하여 이러한 주석을 대체 할 수 있습니다. 그런 다음 다음과 같은 것을 실행할 때 :

vcs blame file.ext

일반적으로 각 행을 변경 한 사람, 변경시기 및 커밋 ID를 포함한 유용한 정보를 볼 수 있습니다. 커밋 ID에서 버그 ID를 포함하는 전체 메시지를 얻을 수 있습니다.

좋은 VCS 시스템을 사용하면 누가 라인을 수정했는지 계산할 때 공백을 무시할 수 있습니다.

이 기능에 대한 Clear Case의 기능을 모릅니다.