개정 역사와 문서화 내가 레거시 시스템에서 작동

Question

을 변경하고 나는 예를 들어, 소스 코드의 모든 자료를 수정되는 파일이나 기능의 개정 기록을 확인하는 데 사용 : 난 그냥이 궁금 해요

// 
// Rev. No  Date  Author Description 
// ------------------------------------------------------- 
// 1.0 2009/12/01 johnc <Some description> 
// 1.1 2009/12/24 daveb <Some description> 
// ------------------------------------------------------- 
void Logger::initialize() 
{ 

    // a = b;    // Old code, just commented and not deleted 
    a = b + c;   // New code 

} 

역사를 문서화하는 방법은 오늘날 많은 사람들이 여전히 연습하고 있습니까? 그렇다면 소스 코드에 수정 사항을 어떻게 적용합니까? 주석을 달거나 완전히 삭제합니까?

그렇지 않은 경우 이러한 수정을 문서화하는 가장 좋은 방법은 무엇입니까? 버전 제어 시스템을 사용하는 경우 필요에 따라 주석을 제외하고 소스 파일에 순수 소스 코드가 들어 있습니다 (각 기능에 대한 개정 내역 등이 없음).

Answer 1

요즘은 이러한 버전을 문서화하는 가장 좋은 방법은 버전 제어를 사용하는 것이지만 개발자가 의미있는 커밋 주석 또는 적어도 일부 버그 추적 번호를 작성하는 규칙을 적용해야한다는 것을 의미하기 때문에 그들이 무엇을 위해 무엇을 저지른 것인지 쉽게 알아낼 수 있습니다.

Answer 2

코드 주석에서 수정 내역을 본 적이 없습니다. 대부분 Javadoc @version 태그가 버전을 문서화하는 것을 보았습니다. 가장 오래된 버전 제어 방법은 다음과 같습니다. logo2007-1.png, logo2007-2.png

버전 제어가 최상의 솔루션이어야합니다.

도 참조 : http://betterexplained.com/articles/a-visual-guide-to-version-control/

Answer 3

매뉴얼 개정 이력을 유지하기 어려운, 그래서 거의 항상 아웃 오브 날짜입니다.

나는이 정보를 제공하기 위해 개정 관리 시스템을 신뢰합니다. 올바른 것 외에도, 예를 들어 사전 라인 주석 (해당 라인을 마지막으로 변경 한 사람)과 같이 훨씬 더 정확할 수 있습니다.

커밋 메시지에서도이 정보를 사용할 수 있다고하더라도 필자는 필요할 때 소스에서 직접 버그 추적 시스템의 티켓을 참조에 삽입합니다.

모든 릴리스에 대해 수동으로 유지 관리되고 업데이트되는 프로젝트 당 변경 사항/릴리스 노트 파일 (소스 파일이 아님)이 있어야합니다.

Answer 4

저는 데이터베이스에 연결된 모든 SP에 대해 이러한 유형의 주석을 요구 한 회사에서 일했습니다. 필자는 소스 제어 시스템에 들어가야하는 메모에 비해 매우 지루하고 완전히 중복됨을 발견했습니다.

인라인 주석의 주된 용도는 새로운 환경으로의 배포가 (생산과 같이) 성공적 이었음을 확인하는 것이 었습니다. 이것은 또한 지루한 과정이었고 다른 방법이 없었기 때문에 사용되었습니다.

다른 곳에서는 인라인 코멘트에 사용 된 적이 없으며 지루한 두통으로 인해 작업을 유도하는 것으로 나타났습니다.

나는 소스 제어가 코드가 아닌 주석과 개정 내역을 관리하는 시스템을지지 할 것이다. 그것이 시스템의 목적 중 하나이며 그 시스템을위한 최고의 장소입니다. IMO.

Answer 5

버전 제어 시스템에만 의존하십시오. 예, 순수한 소스 코드입니다. 코드가 주석 처리 된 경우 삭제됩니다. 확실하지 않으면 TODO 코멘트를 남깁니다. 소스에있는 커밋 메시지의 참조 티켓에 주석을 삽입하지 않았습니다.코드에서 사용한 것처럼 문서화 할 필요가 없습니다.