VCS에서 즉시 중복 파일을 삭제하지 않고 먼저 주석이있는 "삭제"로 표시하는 것은 나쁜 습관입니까?

버전 제어에서 삭제해야하는 소스 파일을 처리하는 방식이 나쁜 습관으로 간주 될 수 있는지 알고 싶었습니다.

그 예를 기반으로 설명하고 싶습니다.

나는 기본적으로 데드 코드 인 프로그램에서 Java 클래스를 신중하게 정렬해야했기 때문에 최근에 매우 화가 나었지만 아무 것도 문서화되지 않았으며 Java 클래스에서도 주석 처리되지 않았습니다. 물론 그것들을 삭제해야했지만 중복 항목을 삭제하기 전에 이상한 습관이있을 수 있습니다.

SVN-> Delete (선택한 버전 제어 시스템의 delete 명령으로 대체)를 통해 이러한 중복 파일을 즉시 삭제하지는 않지만 대신 해당 파일에 주석을 넣습니다 (머리글과 바닥 글 모두 참조). 삭제 + 내 이름 + 날짜 및 더 중요하게- 왜 삭제 되었는가 (내 경우에는 코드가 죽었 기 때문에 혼란 스럽습니다). 그런 다음 저장하고 버전 관리에 커밋합니다. 다음 번에는 프로젝트에서 버전 제어를 위해 커밋 / 체크인해야 할 때 SVN-> 삭제를 누른 다음 버전 관리에서 결국 삭제됩니다. 물론 개정을 통해 복원 할 수 있습니다.

왜 바로 삭제하는 대신 이것을 하는가?

내 이유는, 중복 파일이 존재하는 마지막 개정판에서 명시 적으로 마커를 원하기 때문에 삭제해야 할 이유가 있습니다. 내가 즉시 삭제하면 삭제되지만 왜 삭제되었는지는 문서화되지 않았습니다. 다음과 같은 일반적인 시나리오를 피하고 싶습니다.

"흠 ... 왜 그 파일들이 삭제 되었습니까? 나는 전에 잘 작동했습니다." ( '되돌아 가기'-> 그러면 되돌아 간 사람은 다음 주에 영원히 사라지거나 사라질 수 있습니다. 다음 담당자는 그 파일이 무엇인지 확실하게 나와 같은 것을 찾아야합니다)

그러나 커밋 메시지에서 해당 파일이 삭제 된 이유는 무엇입니까?

물론 나는하지만 동료가 커밋 메시지를 읽지 못하는 경우가 있습니다. 일반적으로 모든 커밋 메시지와 함께 버전 제어 로그를 확인하는 (제 경우에는 죽은) 코드를 이해하려고 시도하는 것은 일반적인 상황이 아닙니다. 동료는 로그를 크롤링하는 대신이 파일이 쓸모 없다는 것을 즉시 확인할 수 있습니다. 그것은 / 그녀의 시간을 절약하고 그녀는 아마도이 파일이 잘못 복원되었을 것임을 알고 있습니다 (또는 적어도 질문을 제기합니다).

소스 제어에서 주석을 삭제하고 설명을 넣는 대신 삭제해야하는 주석을 파일에 추가하는 문제는 개발자가 커밋 메시지를 읽지 않으면 반드시 소스 코드에서 주석을 읽을 것이라는 가정입니다.

외부인의 관점에서 볼 때이 방법론은 매우 보수적 인 소스 제어 관점에 뿌리를 둔 것 같습니다.

"이 사용하지 않는 파일을 삭제 한 다음 누군가 필요로하면 어떻게해야합니까?" 누군가 물어볼 수도 있습니다.

소스 컨트롤을 사용하고 있습니다. 변경 사항을 되돌 리거나 파일을 삭제 한 사람 (의사 소통)과 더 잘 대화하십시오.

"내가 죽은 파일을 삭제하는 경우는, 다음 사람은 다시 사용하기 시작 하고 그들이 변경을?" 다른 사람이 요청할 수 있습니다.

다시 소스 제어를 사용하고 있습니다. 사람이 해결해야하는 병합 충돌이 발생합니다. 마지막 질문과 마찬가지로 여기에 대한 답변은 팀원과 대화하는 것입니다.

파일을 제거해야한다고 의심되는 경우 소스 제어에서 파일을 삭제 하기 전에 통신하십시오 . 어쩌면 최근에 사용을 중단했지만 곧 출시 될 기능에 필요할 수 있습니다. 당신은 그것을 알지 못하지만 다른 개발자 중 하나 일 수 있습니다.

제거해야하는 경우 제거하십시오. 코드베이스에서 지방을 잘라냅니다.

"oopsie"를 만들었고 실제로 파일이 필요한 경우 파일을 복구 할 수 있도록 소스 제어를 사용하고 있음을 기억하십시오.

이 질문에 대한 의견에서 Vincent Savard는 다음과 같이 말했습니다.

... 동료가 커밋 메시지를 읽지 않고 올바르게 삭제 된 파일을 부활시키고 코드 검토를 통과 한 경우 팀에 문제가있는 것이므로 더 잘 가르 칠 수있는 좋은 기회입니다.

이것은 건전한 조언입니다. 코드 리뷰는 이런 종류의 것을 잡아야합니다. 파일이 예기치 않게 변경되거나 파일이 제거되거나 이름이 바뀔 때 개발자는 커밋 메시지를 참조해야합니다.

커밋 메시지가 스토리를 알려주지 않으면 개발자는 더 나은 커밋 메시지를 작성해야합니다.

코드를 삭제하거나 파일을 삭제하는 것을 두려워하는 것은 프로세스에 대한 더 심하고 체계적인 문제를 나타냅니다.

• 정확한 코드 검토 부족
• 소스 제어 작동 방식에 대한 이해 부족
• 팀 커뮤니케이션 부족
• 개발자 측의 잘못된 커밋 메시지

이러한 문제는 해결해야 할 문제이므로 코드 나 파일을 삭제할 때 유리 집에 돌을 던지는 것처럼 느끼지 않습니다.

예, 그것은 나쁜 습관입니다.

파일 삭제를 커밋 할 때 커밋 메시지에 삭제에 대한 설명을 넣어야합니다.

소스 파일의 주석은 현재 보이는 코드 를 설명해야합니다 . 커밋 메시지는 커밋이 변경된 이유를 설명해야 하므로 파일의 커밋 히스토리가 해당 히스토리를 설명합니다.

소스 자체에서 직접 변경 사항을 설명하는 주석을 작성하면 코드를 따르기가 훨씬 어려워집니다. 생각해보십시오 : 코드를 변경하거나 삭제할 때마다 파일에 주석을 달면 곧 변경 내역에 대한 주석이 파일에 스왑됩니다.

내 의견으로는 두 옵션의는 가장 좋은 방법이 아닙니다 , 나쁜 반대로 연습 :

1. 주석을 추가하면 누군가가 해당 주석을 읽는 경우에만 값을 추가합니다.
2. VCS에서 삭제하는 것만으로 (변경 설명의 이유로) 중요한 결과물에 영향을 줄 수 있으며 많은 사람들이 특히 압력을 받고있을 때 변경 설명을 읽지 않습니다.

내가 선호하는 관행 – 주로 수년에 걸쳐 여러 번 물린 적이 있기 때문에 코드가 어디에서 누구에게 사용되는지 항상 알지 못한다는 점을 명심하십시오 .

1. 이 삭제 후보와이 아니라는 코멘트 추가 중단 #warning 또는 유사한을, (대부분의 언어의 예와 같은 메커니즘의 일종,이 자바 최악의 경우, print문 또는 유사한 충분합니다), 이상적으로 날짜 표시 줄의 어떤 종류와 연락처와 함께. 이것은 실제로 코드를 실제로 사용 하고있는 사람에게 경고 합니다. 이러한 경고는 일반적으로 이러한 함수 가 존재하는 경우 각 함수 또는 클래스 안에 있습니다 .
2. 어느 정도 시간이 지나면 경고를 표준 파일 범위로 업그레이드합니다 #warning(일부 사람들은 지원 중단 경고를 무시하고 일부 툴 체인은 기본적으로 그러한 경고를 표시하지 않습니다).
3. 나중에 파일 범위 #warning를 #error이와 동등한 것으로 바꾸십시오. 이렇게하면 빌드시 코드가 손상되지만 반드시 필요한 경우 제거 할 수는 있지만 제거하는 사람은 무시할 수 없습니다. (일부 개발자는 경고를 읽거나 다루지 않거나 중요한 경고를 분리 할 수 ​​없을 정도로 많은 경고를받습니다).
4. 마지막으로 VCS에서 삭제 된 것으로 파일 (기한 날짜 또는 그 이후)을 표시하십시오.
5. 경고 단계에서 전체 패키지 / 라이브러리 / 등을 삭제하면 README.txt 또는 README.html 등을 추가하여 언제 패키지를 제거하고 언제 파일을 제거 할 계획인지에 대한 정보 와 함께 나머지 내용을 제거한 후 일정 시간 동안 패키지의 유일한 내용 으로 삭제 된 시점으로 변경합니다 .

이 방법의 한 가지 장점은 일부 버전 관리 시스템 (CVS, PVCS 등) 이 체크 아웃시 기존 파일이 VCS에서 삭제 된 경우 기존 파일을 제거하지 않는다는 것입니다. 또한 모든 경고를 수정 하고 문제를 해결하거나 삭제에 대해 호소 할 수있는 양심적 인 개발자 에게 도움이됩니다. 또한 나머지 개발자들은 최소한 삭제 알림을보고 많은 불만을지게합니다 .

참고 #warning/ #error인 컴파일러가 가지고있는 코드, 자바 / 자바 문서를 발견 제공된 텍스트 다음에 경고 / 오류 원인이되는 C / C ++ 메커니즘 @Deprecated주석 사용에 & 경고를 발행하는 @deprecated등이 있습니다, 몇 가지 정보를 제공하기를 파이썬에서 비슷한 일을하는 요리법 & 나는 실제 세계에서 assert비슷한 정보를 제공하는 데 사용되는 것을 보았습니다 #error.

예, 나쁜 습관이라고 말하지만 파일과 커밋 메시지에 있기 때문에 아닙니다. 문제는 팀과 의사 소통하지 않고 변경하려고한다는 것입니다.

어떤 방식 으로든 파일을 추가, 삭제 또는 수정하는 트렁크를 변경할 때마다 트렁크로 다시 커밋하기 전에 해당 변경 사항에 대해 직접 팀원과 직접 대화 해야합니다. 그들에 대해 잘 알고 있어야한다. 이렇게하면 (1) 삭제하는 코드를 실제로 삭제해야하고 (2) 팀이 코드가 삭제되었음을 알게되어 삭제 취소를 시도 할 가능성이 훨씬 높아집니다. 추가 한 코드에 대한 버그 감지 등도 제공됩니다.

물론, 큰 내용을 변경할 때는 커밋 메시지에도 넣어야하지만 이미 논의 했으므로 중요한 공지의 출처 일 필요는 없습니다. Steve Barnes의 답변 은 코드의 잠재적 사용자 풀이 너무 큰 경우 (예 : 처음에 파일을 삭제하는 대신 언어의 사용되지 않는 마커 사용) 사용하는 좋은 전략을 제시합니다.

커밋하지 않고 오랫동안 가고 싶지 않다면 (예 : 변경 사항이 여러 개정으로 가장 의미가 있습니다) 트렁크에서 분기를 만들고 분기로 커밋 한 다음 분기를 다시 트렁크로 병합하는 것이 좋습니다. 변화가 준비되었습니다. 이렇게하면 VCS가 여전히 파일을 백업하지만 변경 사항이 트렁크에 영향을 미치지 않습니다.

여러 플랫폼 및 구성을 기반으로하는 프로젝트의 관련 문제. 해서 나는 이 죽은 것으로 판단 않는 것이 올바른 결정의 의미하지. 사용하지 않으면 여전히 제거해야 할 흔적 의존도를 의미 할 수 있으며 일부는 누락되었을 수 있습니다.

그래서 (C ++ 프로젝트에서) 추가했습니다.

#error this is not as dead as I thought it was

그리고 체크인했습니다. 모든 일반 플랫폼을 다시 빌드 할 때까지 기다리십시오. 아무도 그것에 대해 불평하지 않습니다. 누군가 그것을 찾았다면 누락 된 파일로 당황하지 않고 한 줄을 쉽게 제거 할 수 있습니다.

본인은 언급 한 의견이 버전 관리 시스템에서 수행해야하는 기능을 복제하고 있음에 동의 합니다 . 그러나 이를 보완 해야 할 구체적인 이유 가 있을 수 있습니다 . VCS 도구를 모르는 것은 그중 하나가 아닙니다.

나쁜 관행의 연속체에서 이것은 아주 작습니다. 분기를 확인하고 이전 코드를보고 싶을 때 가끔이 작업을 수행합니다. 이를 통해 교체 코드와 쉽게 비교할 수 있습니다. 나는 보통 코드 검토 주석 "크루프 (cruft)"를 받는다. 약간의 설명으로 코드 검토를 통과했습니다.

그러나이 코드는 오래 살지 않아야합니다. 나는 일반적으로 다음 스프린트의 시작 부분에서 삭제합니다.

커밋 메시지를 읽지 않는 동료가 있거나 프로젝트에 왜 코드를 남겼는지 묻지 않으면 문제는 나쁜 코딩 스타일이 아닙니다. 다른 문제가 있습니다.

스턴트를 풀기 전에 클래스를 리팩터링하고 UNUSED_Classname 접두어로 이름을 바꿀 수 있습니다. 그런 다음 삭제 작업을 직접 커밋해야합니다.

• 1 단계 : 수업 이름 변경, 의견 추가, 커밋
• 2 단계 : 파일 삭제 및 커밋

죽은 코드 인 경우 삭제하십시오. 누구나 필요로하며 되돌아 갈 수 있지만 이름 바꾸기 단계를 수행하면 생각없이 직접 사용할 수 없습니다.

또한 파일에 대한 모든 커밋 메시지를 보는 방법을 사람들에게 가르치십시오. 일부 사람들은 그것이 가능한지조차 모릅니다.