80 % 이상 변경 한 경우 클래스 파일에서 작성자 이름을 변경해야합니까?

자동화 된 UI 테스트를 위해 기존 Java 테스트 클래스 세트를 리팩토링하고 있습니다. 때때로 나는 수업 파일을 크게 변경하거나 완전히 개조하는 결과를 얻었습니다. 이것은 전체 클래스를 다시 작성할 때 주석 섹션의 저자 이름을 내 것으로 변경해야한다고 생각합니다.

내가 탐욕 스럽습니까? 아니면 내 이름을보고 의심이가는 경우 물어 보는 것이 도움이 될까요?

정말 달려있다 ...

다른 사람이 나중에 원저자에게 물어 보는 데 관심이있을 가능성이 약간 있다고 생각되면 코드에 그의 이름을 쓰십시오. 누군가가 당신을 직접 물어 보는 데 관심이 있다고 생각되면 이름을 적어 두십시오. 그리고 만약 당신이 생각한다면, 둘 다 가능할 수도 있습니다. 두 이름을 모두 "또는"의 작품을 바탕으로 "와 같은 주석으로 쓰십시오.

물론, 직장에서 소스 제어의 사용이 필수적이며 소스에 액세스 할 수있는 유일한 방법 인 경우 허슬을 저장하고 모든 작성자의 의견을 소스에서 제거하십시오. 예를 들어, 직장에는 소스 제어에 소스 파일이 많으므로 소스에 이름을 쓰지 않아도됩니다. 파일을 책임지고 있거나 과거에 있었거나 특정 변경을 담당 한 사람을 알고 싶다면 TortoiseSVN에서 쉽게 해당 로그를 생성합니다.

반면에, 우리는 일부 사람들이 작성한 많은 VBA 매크로를 가지고 있으며 다른 사람들에게 넘겨 주었고 (일부는 몇 년 동안 회사를 떠났습니다) 소스 제어를 사용하지 않고 많이 수정되었습니다. 운 좋게도 해당 파일의 주석에는 종종 작성자 이름과 일종의 기록 로그가 포함됩니다.

방금 OP가 작성자의 이름이 파일 헤더에 있어야하는지 묻는 또 다른 게시물을 보았습니다. 응답 한 사람의 적어도 2/3가 이름이 나열되어서는 안되며 버전 제어를 사용하여 누가 파일을 변경했는지 추적하기 만하면됩니다. 그 게시물에 무슨 일이 있었는지 모르겠지만 지금은 찾을 수 없습니다. <-(따라서 익명 "OP")

개인적으로 필자는 파일 헤더에 나열된 작성자가 유용하지만 약간 다른 이유로 (이는 해당 환경의 다른 사람들과 관련이 없을 수 있음) 발견했습니다. 커뮤니티 소유권을 연습하고 프로젝트의 다양한 부분에서 종종 일하지만, 특정 코드 영역을 다른 영역보다 훨씬 더 잘 아는 팀 구성원은 거의 없습니다. 따라서 누군가 (특히 수많은 계약자)가 이전에 본 적이없는 파일을 열면 저자가 방문하는 사람이됩니다. 그는 유일하게 기고자 또는 다수의 기고자 일 수는 없지만 맨 위에 이름을 지니고 있기 때문에 코드에 대한 지식 / 정보를 팀의 다른 팀에게 배포 할 책임이 있음을 인정합니다. 여러 사람이 실제로 기여하고 책임감을 느끼는 헤더에 한 명 이상의 사람을 나열 할 수 있습니다.

파일에 대한 질문이 있고 기본 또는 가장 지식이 많은 사람을 식별하기 위해 버전 관리에 의존해야 할 때 좌절감을 느낍니다. 그런 다음 한 사람에서 다른 사람으로 이동하여 코드의 기능을 실제로 알지 못합니다. 그냥 들어가서 버그를 수정해야했습니다.

이 실습은 팀에서 이루어 지므로 핸드 오프가 없습니다. 사람이 종료하거나 다른 팀으로 이사하지 않는 한, 해당 코드 / 프로젝트는 사람과 우리 팀과 함께 유지됩니다. 분명히 코드를 유지 관리하는 사람이 코드를 작성하는 사람과 동일하지 않은 경우 아무도 헤더에 나열된 사람을 신경 쓰지 않을 것입니다.

그래서 파일 헤더에 대한 나의 견해에 비추어, 파일의 80 %를 변경하고 지금 당신은 질문에 대한 이동 사람이라고 생각합니다 (그리고 아마도 그렇게 생각해야합니다). 앞서 파일 이름을 업데이트하여 파일 이름을 업데이트하십시오. 이전 사람을 제거하는 것에 대해 기분이 좋지 않다면, 적어도 한동안 그 이름을 남겨 둘 수도 있습니다. 항상 원본 작성자에게 요청할 수 있으며 파일 자체의 80 %를 변경하는 것에 대해 아무런 느낌이 없다고 가정하기 때문에 이름을 변경했다고 생각하지 않을 것입니다.

업데이트 : 해당 게시물을 찾았 습니다 . 8 월부터 어떻게 되 찾을 수 있었는지 모르겠다. 나는 Pragmatic Programmer를 읽었고 마지막 장에서 저자는 일과 책임에 서명하는 것에 대해 이야기했습니다 (다른 게시물에서 언급 했으므로 그것을 찾았습니다). 이 책은 완벽하게 이해가되었으며 이제는 생각합니다. 아마도 저자로 등재 된 사람이 문제의 파일의 모든 코드 검토에 포함되어야한다는 팀 정책을 소개해야합니다. 누가 SVN에서 파일을 마지막으로 또는 가장 많이 변경했는지는 중요하지 않지만 작성자는 소유자이며 키퍼입니다.

저자의 이름이별로 유용하지 않습니다. 이 질문에서 알 수 있듯이 종종 단일 저자가 없으므로 "저자"라는 이름을 지정할 수 없습니다.

물론 중요한 기여를 한 모든 사람들의 목록을 포함시킬 수는 있지만 이미 개정 관리 로그에서 얻을 수 있습니다. 요점은 무엇입니까?

내 프로젝트에는 대부분의 파일에 저자 정보가 없습니다. 궁금한 점이 있으면 로그를 살펴보면 일반적으로 한두 사람이 대부분의 작업을 수행 한 것이 분명하므로 물어보십시오.

편집하다

답은 버전 관리를 사용하는 프로젝트를 가정합니다. VC를 (일관되게) 사용하지 않으면 작성자 (목록)를 넣고 일부 변경 기록을 파일에 넣을 수 있습니다. 여전히 VC를 가능한 빨리 시작해야합니다.이 경우 위의 :-)를 참조하십시오.

파일이 크게 수정 된 경우 파일에 이름을 알고있는 사람으로 파일에 이름을 추가 할 수 있습니다.

소스 파일의 작성자는 항상 소스 파일에 언급해야합니다 (IMHO). 이것은 좋은 헤더 주석으로 저자가 소스를 개발 한 이유와 코드 작성에 대한 생각을 보여 주어야합니다. 코드 관리자는 소스 관리자 추적에 관리자 이름을 추가하는 것이 중요합니다.

IMHO의 저자 이름은 버전 제어 시스템 외부 에서 변경이 발생한 최초 날짜와 변경 요청 번호를 포함하여 코드의 소스 버전을 포함해야합니다 . 그 이유는 VCS를 변경하기로 결정한 경우 코드 버전, 작성자가 누구인지, 개발자가 참조 할 수있는 변경 요청 번호 (관리자가 자신이 수행 한 이유를 알아야하는 경우)가 기록되어 있기 때문입니다. 그녀는 한). 따라서 조직에서 형식은 다음과 같습니다.

/**
 * $comment
 * <p />
 * $cr_number, $date, $author, $description 
 **/

코드에 대한 답변을 찾기 위해 누군가를 찾을 수만 있다면 원래 저자의 이름을 보는 것이 좋습니다. (저자는 일반적으로 기억력이 없지만 적어도 한 번은 탄환입니다!)

원본 저자 아래에 이름을 추가하는 것이 좋습니다.

다른 사람의 이름을 바꿀 필요는 없습니다. 원래 비즈니스 요구 사항 의 일부 측면을 알고있을 수도 있고 그 이후에 다른 사람들도 그 사람과 대화해야 할 수도 있습니다.

@author 의견에 대한 내 정책은 다음과 같습니다.

1. 새 파일이라면 @author라고 생각합니다.
2. 기존 파일 인 경우 파일에 대한 작업에 관계없이 @author를 그대로 둡니다.

무언가에 대한 질문이 있으면 파일의 @author가 누구인지는 중요하지 않습니다. 편집중인 파일의 어느 부분에 대한 @author가 누구인지는 중요합니다. 그게 다야 [git/svn/whatever] blame.

IMO, @author는 떠나야합니다.