코드 작성자를 어떻게 추적합니까? [닫은]


14

이것은 내가 배운 적이없는 것입니다. 다양한 유형의 제작 스타일을 보았습니다. 나는 주로 자바와 파이썬으로 코딩한다. 표준 저작 스타일이 있는지 또는 모든 것이 자유형인지 궁금합니다. 또한 대답 할 경우 집이나 직장에서 만든 파일을 작성하는 데 사용하는 스타일을 첨부해도됩니다.

나는 보통 그냥 간다

@author garbagecollector
@company garbage inc.

3
코드를 변경 한 사람의 이름은 어디에 있습니까?
JeffO

@Jeff 어디서 어떻게 보입니까?
dustyprogrammer

그렇게하는 것은 말이되지 않습니다. 왜 그렇게 하시겠습니까?
CodeART

답변:


-1

당신이 무엇을 요구하는지 완전히 알지 못하지만, 나는 매우 엄격한 스타일을 사용합니다.

;==========================================
; Title:  Author Style Sample
; Author: Darknite
; Date:   7 Jan 2011
;==========================================

이 스타일은 어셈블리 프로그래머로부터 영감을 받았습니다.

클래스, 텍스트 파일 또는 SQL 저장 프로 시저 등에 관계없이 "작성자"가 필요한 페이지의 맨 위에 이것을 넣었습니다.


이것은 내가 찾고있는 라인을 따라 있습니다.
dustyprogrammer

5
-1 이것은 ( 업데이트 되면 ( 많은 사람들에 의해 코드가 변경 될 때) 많이 성장합니다 ) 효과적으로 버전 관리로 대체됩니다
Michael Durrant

1
@MichaelDurrant 당신은 괄호를 닫는 것을 잊었다;) 어쨌든 시원합니다. 나는 펭귄을 좋아한다.
Darknight

4
@Giorgio 실제로는 ... 파일에 남은 원본 작성자의 한 줄의 코드가 없을 수도 있습니다. 무의미합니다.
Wilbert

1
@Wilbert : 물론 그것은 또한 팀의 정책에 달려 있습니다. 공유 코드 소유권으로 인해 파일 작성자를 추적하는 것은 의미가 없습니다. 개별 코드 소유권을 가진 사람은 누가 어떤 파일을 담당 하는지를 아는 것이 중요합니다.
Giorgio

71

왜 네가? 그것이 버전 관리 시스템과 "Blame"의 역할입니다. :)


8
버전 관리 ftw.
폴 나단

1
버전 제어 시스템 (VCS)이 아닌 소스 코드 관리 (SCM)로 생각하면 그렇게하는 것이 더 합리적입니다.
Peter Eisentraut

작은 제한, 외관상의 변화 (들여 쓰기 등)는 라인의 저자를 변경합니다 ...
Matthieu M.

4
@Matthieu : 좋은 SCM은 마지막으로 만지는 것이 아니라 시간이 지남에 따라 어떤 변화가 있었는지 보여줄 수 있습니다. 또한 미용 변화도 변화라고 주장 할 수도 있습니다.
grossvogel

1
이 답변은 8 세 이상이며 아무도 그 제한을 보지 못했습니까? 소스 코드가 전체 수명 시간 동안 하나의 VCS에 머 무르거나 제대로 마이그레이션 된 경우에만 적용됩니다! 그러나 많은 오픈 소스 코드가 때때로 서로 다른 환경간에 전송되므로 작성자 정보가 소스 코드에 직접 작성되지 않으면 작성자 정보가 전달되지 않을 수 있습니다.
Doc Brown

11

우리는 회사에서 저작하지 않습니다. 대신, 버전 관리에서 처리하도록합니다.

체크인 할 때마다 사용자 이름이 변경 목록에 첨부됩니다. 무언가가 깨지면 누군가가 돌아가서 변경 내역을보고 무엇이 변경되었는지, 언제, 누가했는지 확인할 수 있습니다. 또한 시간이 지남에 따라 파일이 어떻게 진화했는지, 누가 만졌는지, 어떤 프로젝트에서 그 파일이 분기되었는지를 확인하기 위해 개정 그래프를 깔끔하게 살펴 봅니다.

클래스에 작성자 태그를 넣을 때의 문제점은 시간이 지남에 따라 둘 이상의 개발자가 해당 클래스에서 작업 할 가능성이 높다는 것입니다. 업데이트 등. 저자의 의견을 업데이트하는 추가 단계이며 추가 단계가 많이 잊어 버리는 경향이 있습니다. 따라서 빨리 만료됩니다.


10

나는 전혀하지 않습니다. 직장에서 파일을 마지막으로 수정 한 사람의 회사 이름과 사용자 ID가있는 파일에 삽입되는 템플릿이 있다고 생각하지만 결코주의를 기울이지 않습니다.

일반적으로 나는 그것이 당신이 어떻게하는지 중요하지 않다고 생각합니다. 파일을 제작 스탬프 찍으려면 일관된 스타일을 선택하여 사용하십시오.


6

JavaDoc은 Java 커뮤니티에서 매우 표준입니다.

http://download.oracle.com/javase/1.3/docs/tooldocs/win32/javadoc.html#@author

@author 이름 텍스트

-author 옵션이 사용될 때 지정된 이름 텍스트 가 있는 "작성자"항목을 생성 된 문서에 추가합니다. 문서 주석에는 여러 개의 @author태그 가 포함될 수 있습니다 . @author태그 당 하나의 이름 또는 태그 당 여러 이름을 지정할 수 있습니다 . 전자의 경우 Javadoc은 쉼표 (,)와 이름 사이에 공백을 삽입합니다. 후자의 경우 전체 텍스트가 구문 분석되지 않고 생성 된 문서에 복사됩니다. 따라서 쉼표 이외의 지역화 된 이름 구분 기호를 사용하려면 한 줄에 여러 이름을 사용하십시오.


5

버전 관리 시스템에 가장 적합하다고 생각합니다.


4

나는 GIT 의 비난 기능을 좋아한다 . 각 코드 / 라인을 작성한 사람을 볼 수 있습니다. 파일 만이 아닙니다.


다른 VCS는 같은 것을 가지고 있습니다 (종종 "비난"이라고도 함).
Richard

GIT에 따라 다르기 때문에 -1이됩니다. OP는 GIT를 언급하지 않았습니다. 그러나 아아, 나는 downvote에 대한 충분한 담당자가 없습니다.
Thomas Eding

2

기고자가 많은 대규모 프로젝트를 수행하는 경우 작성자 목록으로 각 파일에 주석을 달면 작동하지 않습니다. 파일을 여러 개의 작은 파일로 나눌 때 작성자 목록으로 무엇을합니까? 코드를 완전히 다시 작성하면 원래 작성자 이름을 유지합니까? 댓글에서 오타를 수정할 때 저자 목록에 이름을 추가합니까?

이러한 질문은 버전 관리 시스템에 더 적합합니다.

그러나 나는 저자 목록에 완전히 반대하지 않습니다. 전체 프로젝트의 저자 목록을 유지하는 것은 완벽합니다. 단일 파일 프로젝트 인 경우 반드시 해당 파일 안에 보관하십시오. 더 큰 프로젝트 인 경우 README 또는 최상위 소스 파일 (일명 main.c)에 보관하십시오. 그러나 모든 단일 파일에 작성자를 나열하여 자신을 반복하지 마십시오.


1

우리는 버전 관리 시스템을 사용하거나 @author코드 에 배치하여 추적 합니다. 이를 수행하는 또 다른 방법은 특정 사람들이 전체 모듈 또는 전체 프로그램의 저자라고 더 일반적으로 말하는 것입니다. 이를 통해 사람들은 정확히 X 개의 함수 또는 코드 라인을 담당하는 기계의 톱니가 아닌 팀의 일부로 자신을 생각하게됩니다.


0

나는 거의 모든 것에 Doxygen 스타일 (또는 때로는 KernelDoc) 주석을 사용합니다. 나는 주로 Doxygen이 많이 사용되는 C와 PHP에서 일합니다.

대부분의 경우 최소한 다음 정보를 포함하는 것이 좋습니다.

  • 복사 또는 회사 또는 개인의 저작권에 대한 허가
  • 저자 이름 / 이메일
  • 작성된 날짜
  • 마지막으로 수정 한 날짜

파일 작업을하는 사람은 무엇을 가지고 있는지, 파일로 무엇을 할 수 있는지, 필요한 경우 도움을 요청할 수있는 사람을 알 수 있어야합니다. 또한 10 살짜리 무언가를보고 있는지 알려줍니다.


0

다른 사람들이 말했듯이 버전 관리에 추가 문서가 있기 때문에 개인적 으로이 작업을 수행하지 않습니다. 그러나 어떤 종류의 쿵푸 코드 스 니핏을 만들려면 IDE가 자동 생성 할 수있는 모든 것과 함께 할 수 있습니다.

예를 들어, 유용한 CNTools가 설치된 델파이 7에서 사용하면

///a [enter]

그리고 나옵니다

//<author></author>

그런 다음 입력

///d [enter]

그리고 나옵니다

 //<date></date>

나는 그것이 일부 타사 유틸리티가 선택할 수있는 것에 해당한다고 상상할 수 있지만, 나에게는-나 자신을 구성하고 손상시킬 필요조차없는 표준이 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.