참조되지 않은 코드를 제거해야합니까?

나는 중간 크기 (100k 라인) 코드베이스에서 일하고 있는데, 모두 비교적 최근 코드 (1 년 미만)이며 단위 테스트 적용 범위가 좋습니다.

더 이상 어디서나 사용되지 않거나 특정 방법 만 테스트하는 단위 테스트에서만 참조되는 방법을 계속 사용합니다.

더 이상 필요하지 않은 경우이 코드를 제거해야합니까?

제거 이유 :

• 적은 코드, 적은 버그
• 적은 코드는 다른 사람들이 쉽게 소화 할 수
• 여전히 소스 제어하에 있습니다

그것을 지키는 이유 :

• 참조로 사용할 수 있습니다
• 언젠가 유용 할 수 있습니다
• 클래스의 기능을 '반올림'하도록 작성되었을 수 있습니다.

그것을 유지 해야하는 대부분의 이유는 전혀 관련이 없습니다. 간단히 말하면. 코드를 사용하지 않으면 버려야합니다. 코드를 유지하는 데 관련된 모든 이점은 소스 제어에서 사소하게 파생 될 수 있습니다. 기껏해야 어떤 개정 버전을 찾을 수 있는지 의견을 남겨주십시오.

간단히 말해 코드를 빨리자를수록 유지 관리, 컴파일 및 테스트에 시간을 낭비하지 않아도됩니다. 이러한 이점은 사용자가 요약 한 사소한 이점보다 훨씬 뛰어납니다.이 모든 이점은 소스 제어에서 파생 될 수 있습니다.

그것을 제거 해야하는 모든 이유는 유효합니다.

그것을 지키는 이유 :

• 참조로 사용할 수 있습니다
• 언젠가 유용 할 수 있습니다
• 클래스의 기능을 '반올림'하도록 작성되었을 수 있습니다.

이를 유지해야하는 모든 이유는 소스 제어로 관리됩니다. 라이브 코드에서 코드를 제거하면 필요할 때 검색 할 수 있습니다.

참조되지 않은 코드는 횃불을 위해 하루가 필요한 경우를 대비하여 다소 평평한 배터리를 유지하는 것과 동일합니다.

어떤 종류의 버전 제어를 사용하는 한 라이브 코드에서 버리고 버전 기록을 사용하여 유용하다고 말하고 싶습니다.

현재 사용되지 않는 코드를 유지하는 유일한 이유는 자체 포함 모듈의 일부인 경우입니다. 코드의 일부가 현재 사용되지 않을 수 있지만 코드가 제대로 작동하지 않을 수 있습니다. 미래에 사용됩니다.

다른 프로젝트에서 사용하는 라이브러리의 경우 특히 그렇습니다. 특정 프로젝트에 필요한 코드에 따라 코드 조각을 계속 던져 넣기를 원하지 않습니다.이 시간이 많이 걸리고 오류가 발생하기 쉽습니다.

나의 접근 방식은 : (1) 한 번만 사용하면 실제로 필요한 것만 유지하십시오. (2) 두 번 사용할 경우 두 번째로 사용할 때 복사하여 적용하십시오. (3) 두 번 이상 사용하는 경우 잘 정의되고 안정적인 모듈을 만들어 필요한 경우이 모듈을 사용하십시오.

요약 : 당신이 디자인 한 범용 모듈의 일부가 아니며 여러 번 재사용 할 것이라는 것을 알지 못하면 사용하지 않는 모든 코드를 버릴 것입니다.

참고 : 물론 더 깨끗한 솔루션은 라이브러리에 대해 별도의 프로젝트를 만들고 프로젝트간에 종속성을 추가하는 것입니다.

일반적으로 나는 이것에 YAGNI에 절을 할 것입니다. "필요하지 않다"면 코드베이스, 단위 테스트 및 어셈블리에서 공간을 차지하는 것입니다. 당신은 그것을 필요로 할 수도 있지만, 지금과 당신이 그것을 필요로 할 때 많은 것이 바뀔 수 있기 때문에 그것을 완전히 다시 써야 할 수도 있습니다.

그러나 일반적인 소비를위한 유틸리티 또는 API를 작성할 때 약간 변경됩니다. 소프트웨어 최종 사용자가 의도 한 방식으로 소프트웨어와 상호 작용할 것으로 기대할 수없는 것처럼, 코드 ​​소비자가 원하는 방식대로 코드를 사용하기를 기대할 수 없습니다. 그러한 경우, "내 객체와 상호 작용하고 싶은 유효한 방법"으로 메소드의 존재를 정당화 할 수있는 한, 아마도 필요하지 않더라도 기회는 좋기 때문에 아마도 들어가야 할 것입니다. .

코드베이스가 1 년 미만인 것을 감안할 때 여전히 많은 플럭스 (예?)에 있습니다. 따라서 가까운 미래에 일부 비트를 부활시켜야한다는 개념은 부당하지 않습니다.

처음부터 제대로 맞추기 어려웠고 부활 될 가능성이 높은 비트의 경우 소스 제어보다 조금 더 "실제"로 유지합니다. 사람들은 자신이 존재한다는 것을 모르거나 기억하지 못합니다. "소스 제어에서 찾을 수 있습니다"라고 말하면 그것이 있다는 것을 알고 기억합니다! 이러한 경우에는 사용 중단 ( "assert (false)"showstopper 사용) 또는 주석 처리를 고려하십시오.

코드가 사소하고 흥미롭지 않으면 소프트웨어 시스템의 불필요한 관성을 제거하기 위해 버립니다.

흥미로운 코드 안내자를 위해 archive버전 관리 시스템에서 분기를 사용 합니다.

"참조로 사용할 수 있습니다"나는 사용하지 않는 코드를 남겨 두는 좋은 이유에 동의하지 않는 경향이 있습니다. 종종 사용되지 않는 코드의 작은 부분 만이 실제로 흥미로운 것을 보여줍니다. 유용하지만 사용되지 않은 코드를 문서화하고 저장하는 방법에는 여러 가지가 있습니다.

버전 제어에는 나중에 코드가 필요한지 결정한 경우 특정 기능을 쉽게 복원 할 수있는 기록이 포함되어 있지만 이전 개정이 무엇인지 아는 사람으로부터 xy 또는 z를 찾으려면 버전 제어 기록을 찾아야합니다. 당신이 찾고있는 것을 상당히 구체적으로 생각하지 않는 한 약간 지루하고 종종 간과됩니다.

코드는 언제 제거되었는지, 왜 코드에서 단순히 삭제되지 않았는 지에 대한 주석으로 주석 처리 될 수 있습니다. 그러나 이것은 일반적으로 나쁜 스타일로 간주되며, 적절하게 사용되지 않고 유지 관리되지 않는 코드는 나중에 주석 처리를 제거하면 모든 종류의 버그를 유발할 수 있으므로 일반적으로 리팩토링하는 동안 임시 디버깅 / 테스트 단계로 사용하는 것이 좋습니다 생산 코드를 남기는 방법.

삭제 된 코드를 저장하는 가장 좋아하는 방법은 나중에 유용 할 것 같으면 여러 가지 가치있는 삭제 된 코드를 모두 포함하는 보조 참조 문서를 만드는 것입니다. 각 코드 블록에는 코드가 어디에서 왔는지 또는 코드가 제거 된 시점 또는 코드의 마지막 개정 번호와 같이 기억해야 할 기타 사항이 간략하게 언급되어 있습니다. "잠재적으로 유용한"항목은 모두 제거 할 수 있지만 한 곳에서 쉽게 검색 할 수 있지만 지속적인 유지 관리 및 테스트를위한 지속적인 노력이 필요하지 않습니다 (코드가 다시 도입되는 시점에 따라 테스트가 지연됨).

사용하지 않는 방법을 유지해야하는 한 가지 좋은 이유는 다른 가지 / 태그에 사용할 수 있다는 것입니다.

모든 활성 브랜치 및 태그를 탐색 한 후 제거하십시오.

버전 관리 시스템을 사용하는 경우 나중에 해당 코드의 기록을보고 삭제 된 부분을 찾을 수 있으므로 향후 참조에 대해 걱정하지 마십시오. 당신이하지 않고 언젠가 사용될 것이라고 생각되면, 단순히 거기에 머물러있게하고 왜 주석이 달린 이유를 설명하는 설명으로 주석을 달아주십시오 .

그러나 나중에 사용하지 않을 것이라고 확신하는 경우 간단히 제거하십시오 . 당신이 언급 한 이유는 코드를 제거하기가 매우 간단하다고 생각합니다.

그러나 제거하기 전에 사용하지 마십시오. Visual Studio에는 전체 솔루션을 검색하고 현재 변수, 메서드, 속성, 클래스, 인터페이스 등에 대한 참조를 찾는 모든 참조 찾기 라는 기능 이 있습니다. 코드의 일부를 제거하기 전에 항상 참조가 없는지 확인합니다.

필자는 정확히 필요한 기능을 수행하는 것처럼 보이는 기능을 찾고 오랜 시간 동안 프로덕션 환경에 있었기 때문에 실제로 작동하지 않았 음을 알기 위해 노력하는 경험을 비교적 자주 경험했습니다. 몇 년. 사용되지 않은 코드는 유지 관리되지 않으며 몇 년 전에 작동했을 수도 있지만 API는 신뢰할 수 없을 정도로 변경되었습니다.

기껏해야 실제로 원하는 시간을 실제로 유지하는 데 많은 시간을 소비하게됩니다. 최악의 경우 나중에 불쾌한 버그로 물릴 때까지 작동하는 것으로 보이며 "생산 테스트 된"코드가 작동한다고 가정하여 문제를 새 코드의 다른 곳에 두어야하므로 추적 시간이 더 오래 걸립니다. 내 경험에 따르면, 항상 새로운 기능을 직접 작성하는 것이 항상 더 빠릅니다.

당신이 그것을 삭제했지만 비교적 빨리 당신이 실제로 필요한 것을 발견하면, 그것은 바로 소스 제어에 있습니다. 너무 많은 시간이 지날 때까지 필요하지 않으면 소스 제어에 있다는 것을 기억하지 못하면 어쨌든 처음부터 작성하는 것이 좋습니다.

코드가없는 것보다 적은 시간을 소비하는 것은 없습니다.

코드베이스에 들어가야한다면, 알아낼 시간이 필요하고, 그 코드가 어떤 용도로 사용되는지, 그리고 아무 것도 사용되지 않으면 더 많은 시간이 필요합니다.

좋아-이것은 치유 될 수있는 의견이지만, 다시 말하지만,이 사용되지 않는 코드가 왜 코드베이스에 있는지, 왜 제거되어야하는지 여부에 관계없이 모든 사람들이 이유를 알 것입니다.

아무것도 없으면 아무도 그것으로 시간을 잃지 않을 것입니다.

제대로 이해하기 어려우면이 코드가 존재한다는 훌륭한 문서가 필요하지만 코드베이스가 일부 반복을 통해 발전하는 경우 다시 활성화되면 더 이상 작동하지 않을 수 있습니다.

사용하지 않는 코드를 제거하십시오-혼란이 적고 이해가 낫습니다. 버전 관리 시스템이 관리합니다. 또한 메모장보다 나은 것을 사용하는 경우 환경에서 참조 용으로 이전 코드를 사용할 수 있습니다.

오래된 코드에 대한 긴 의견은 산만하고 탐색하기가 어렵습니다.

문안 인사

이 간단한 알고리즘을 따르십시오.

1. SCM에 백업됩니까? 그렇다면 3으로 이동하십시오.
2. SCM을 설정하십시오.
3. 물건을 버리십시오 .

제거에 찬성하는 모든 포인트가 유효합니다.

클러 터를 찾거나 복원 할 SCM이 있으면 클러 터 유지에 유리한 모든 포인트가 유효하지 않습니다. 실제로 SCM은 해당 코드가 올바르게 사용 된 경우 해당 코드가 존재하고 사용되지 않는 이유를 파악하는 데 도움을 줄 수 있어야합니다.

이유를 "데드 코드"라고합니다. 죽고 평화롭게 쉬십시오.

소스 제어 상태를 유지합니다. 활성 코드베이스에 머물러서는 안됩니다.

한 가지 예외는 코드가 디자인을 완료하고 코드를 사용하지 않는 동안 결국 코드를 ​​공개 할 계획이고 다른 사람들은 기본 기능을 원할 수 있습니다. 그런 다음 코드의 다른 부분이 다른 사람들이 이러한 코드의 부분을 사용할 수 있도록 제안하는 방식과 유사한 코드 부분이 작동하는지 확인하기 위해 테스트를 설계하십시오. 그러나 코드 삭제를 고려하고 있고 유지할만한 확실한 이유가 없다면 코드를 사용해야합니다. 사용하지 않는 코드는 모든 사람에게 더 많은 작업을 제공합니다 (코드를 읽기가 어렵고 코드가 깨질 수 있으며 유지 관리해야하는 작업이 많음 등).

내 경험상, 사용하지 않는 코드를 제거하면 역효과를 겪을 수 있습니다. 당신은 당신이 그 코드를 가지고 있다는 것을 잊어 버릴 수 있으며 역사에서 그것을 찾지 않을 것입니다. 또는 누군가 해당 코드를 구현 한 다음 나중에 제거했는지 알지 못할 수도 있습니다. 다시, 당신은 역사에서 그것을 찾지 않을 것입니다 ...

의심의 여지없이, 사용되지 않은 코드를 갖는 것은 나쁜 냄새입니다.

업데이트 : 나는 Ed Staub이 매우 비슷한 대답을 한 것을 보았습니다.