소스 컨트롤에 유용한 삭제 된 코드가 있는지 확인하는 방법은 무엇입니까?

9

그래서 나는이 질문을 읽고있었습니다. 참조되지 않은 코드를 제거해야합니까?

코드 중 일부는 나중에 필요할 경우에 대비하여 참조를 위해 소스 제어에 있으므로 참조되지 않은 코드를 삭제하는 것이 좋습니다.

이후 버전의 사용자 (또는 다른 프로그래머)가 나중에 찾을 수 있도록이 삭제 된 코드를 어떻게 구성합니까? 어떻게 든 소스 제어에서 별도의 브랜치를 만들거나 태그를 지정합니까?

이전에 소스 제어에서 삭제 된 코드를 다시는 부활시키지 않았으며, 대부분 코드를 사용하여 여전히 존재하는 코드의 변경 사항을 추적했습니다. 다른 사람의 실험 작업을 포함하기 전에 지점을 참조 했으므로 트렁크에서 삭제 된 흥미로운 코드 섹션을 표시하는 좋은 방법 일 수 있습니까?

version-control

— 피터 스미스
소스

어떤 vc가 avout을 요구하고 있습니까? 같은 소리 SVN

— 모기

svn은 내가 염두에두고 있지만 모든 소스 제어에 적용 할 수 있다고 생각합니다.

— 피터 스미스

당신은 "내가 더 염두에 둔 것은 대답에 대한 반응으로 프로젝트가 취소되거나 연기된다"고 말합니다. "참조되지 않은 코드"와는 상당히 다르기 때문에 질문을 편집해야한다고 생각합니다.

— Pieter B

6

지점에서 실험하고 있고 어떤 솔루션이 궁극적으로 재 통합 될지 아직 확실 하지 않은 경우 일반적 으로 삭제 된 코드를 참조 하지 않습니다 .

아주 드물지만 지금 당장 문제를 해결하는 것을 막연하게 기억하는 제거 된 코드를 명시 적으로 파헤칠 수도 있습니다 . 그러나 삭제 된 코드가 표시되는 가장 일반적인 이유는 백 로그를 통해 응용 프로그램의 현재 코드 또는 동작을 기록 코드 또는 동작과 관련하여 이해하는 경우입니다.

구체적으로, 당신은 ...

일반적인 코드 검토 / 리 팩터 이해
버그 X를 도입 한 커밋 찾기
호기심 만족 / 버그 해결 커밋 찾기
기능 또는 유사한 기능을 다시 구현
존재하지 않는 코드와 함께 작동 하는 것처럼 보이는 코드 또는 데이터 이해

... 등

이 경우 일반적으로 이전 코드를 부활 시키지 않습니다 . 컨텍스트 나 안내를 위해 제거 된 코드를 사용하여 현재 보고있는 내용을 이해하고 있습니다 .

— Svidgen
소스

4

대답은 다음과 같습니다. 대다수의 프로그래머는 삭제 된 코드를 참조 할 필요가 없습니다. 몇 가지 이유가 있습니다. 내 마음에 오는 몇 가지 이유는 다음과 같습니다.

아마도 가장 중요한 것은 순수한 게으름입니다.
대부분은 일부 코드를 부활시킬 필요성을 느끼지 않았으므로 코드를 쉽게 부활시킬 동기를 부여한 경험이 없습니다.
삭제 된 대부분의 코드는 이유 때문에 삭제됩니다. 일반적으로 다른 더 우수하고 기능적으로 동등하거나 더 강력한 코드로 대체됩니다. 왜 누가 열등한 코드를 부활시키고 싶습니까?

이것은 또한 심리적 문제이기도합니다. 대부분의 프로그래머는 자신의 작업 결과를 매우 자랑스럽게 생각합니다. 그들이 대체 한 것에 여전히 가치가 있다는 것을 어떻게 생각할 수 있었습니까?
대부분의 코드는 완전히 삭제되지 않고 교체되었으므로 전환에서 변경된 인터페이스는 새 코드에서 도입 된 일부 회귀로 인해 삭제 된 코드를 실제로 추적해야하는 경우 충분한 정보를 제공합니다.

그러나 죽은 코드에 대해이 무시의 배후에있는 정당한 이유와 관계없이 프로그래머의 입장에서는 실제로 "무관심"이라고 생각합니다. 그리고 삭제 된 물건을 어떤 식 으로든 다른 식으로 표시하려고해도 그 노력으로 철저히 무시할 준비를하십시오 ...

— cmaster-모니카 복원
소스

왜 그런지 대답하려고 노력할 것 같아요. 코드를 교체하면 짧은 시간이 지나면 의미가 있으며 삭제 된 코드는 더 이상 필요하지 않습니다. 내가 더 염두에 둔 것은 취소되거나 연기 된 프로젝트입니다. 특히 많은 양의 기능이 개발 또는 변경되었지만 궁극적으로 완전히 완성되지 않고 현재 생산에 사용되지 않는 기능.

— 피터 스미스

1

@PeterSmith : 해당 코드에 대해 별도의 분기를 만들어야합니다. 그러면 코드가 작업 브랜치에 존재하지 않으므로 코드를 삭제할 필요가 없습니다.

— JacquesB

@JacquesB가 말한 것에 더하여, 전혀 사용되지 않는 코드가 있으면 오히려 빨리 구식 화되는 경향이 있습니다. 5 년이 지나면 1 년 후에 죽은 지점을 다시 시작할 수 있습니다. 처음부터 다시 시작해야합니다. 죽은 지점은 여전히 아이디어의 원천으로 유용 할 수 있지만 코드 자체는 더 이상 사용할 수 없습니다.

— cmaster-monica reinstate

1

이 질문은 아마도 "버그 데이터베이스와 시스템 요구 사항에 대한 VCS 체크인의 추적 성을 유지하는 방법은 무엇입니까?"

사람들이 소스 제어에서 코드를 부활시키는 시간은 실수로 무언가가 깨져서 다시 가져와야 할 때가되는 경향이 있습니다.

이 시나리오에서 제거 된 특정 코드를 찾는 사람에게 가장 중요한 것은 요구 사항 데이터베이스와 버그 추적 도구를 통해 쉽게 추적 할 수 있다는 것입니다. 특정 요구 사항 또는 기능을 설명하는 단어를 검색 할 가능성이 있기 때문입니다. 소스 파일의 이름이나 제거 된 클래스 / 함수를 알지 못할 것입니다.

릴리스 전에 제거해야하는 흥미롭고 실험적인 코드를 추적하려면 "사용하지 않은 코드 제거 ..." 행을 따라 "버그"티켓으로 간단히 추적하면됩니다 . 또는 프로토 타입 기능 을 위해 시스템에 새로운 유형의 티켓을 도입 할 수도 있습니다 .

따라서 VCS 시스템에서 분기 / 태그를 사용하여 삭제 된 코드를 추적하지 말고 질문에 직접 대답하려면 변경 내용 추적 도구를 사용하십시오.

— 벤 코텔
소스

0

이 조언은 "경우에 따라"코드베이스에서 쓸모없는 코드를 유지하려는 사람들을위한 것입니다. 코드는 여전히 소스 제어에 존재하므로 삭제를 두려워하지 않아야합니다. 요점은 더 이상 필요하지 않기 때문에 삭제 된 코드를 실제로 구성하지는 않습니다. 커밋에서 변경 및 삭제 된 내용을 나타내는 커밋 메시지를 추가하기 만하면됩니다. 삭제 된 코드와 가장 관련이있는 커밋 메시지는 코드가 처음 추가 될 때의 메시지이며 다시 삭제 될 때의 메시지가 아닙니다.

"실험 작업"은 실제로 다른 문제입니다. 별도의 지점이 있어야합니다.

— 자크 B
소스