코드 범위는 사용되지 않은 방법을 강조합니다. 어떻게해야합니까?

기존 Java 프로젝트의 코드 적용 범위를 늘리는 작업을 수행했습니다.

코드 커버리지 도구 ( EclEmma )가 어디서나 호출되지 않은 일부 메서드를 강조 표시했습니다.

저의 초기 반응은 이러한 방법에 대한 단위 테스트를 작성하는 것이 아니라 해당 라인 관리자 / 팀에 강조 표시하고 이러한 기능이 시작되는 이유를 묻는 것입니다.

가장 좋은 방법은 무엇입니까? 그들을 위해 단위 테스트를 작성하거나 그들이 왜 있는지 질문합니까?

1. 지우다.
2. 범하다.
3. 잊다.

이론적 해석:

1. 죽은 코드가 죽었습니다. 그 설명으로 목적이 없습니다. 그것은 한 시점에서 목적을 가지고 있었을 지 모르지만 사라 졌으므로 코드는 사라져야합니다.
2. 버전 관리는 (내 경험상) 누군가가 나중에 해당 코드를 찾기 위해 찾아 오는 희귀 한 독특한 이벤트를 검색 할 수 있도록합니다.
3. 부작용으로, 죽은 코드를 테스트하지 않는 한 아무 것도하지 않고 코드 적용 범위를 즉시 향상시킬 수 있습니다.

주석으로부터의주의 사항 : 원래의 대답은 코드가 의심 할 여지없이 죽었 음을 철저히 확인했다고 가정했습니다. IDE는 오류 가 있으며 실제로 보이지 않는 코드를 호출 하는 몇 가지 방법이 있습니다. 확실하지 않으면 전문가를 데려 오십시오.

다른 모든 답변은 문제의 방법이 실제로 사용되지 않았다는 가정에 근거합니다. 그러나 질문은이 프로젝트가 자체 포함되어 있는지 또는 어떤 종류의 라이브러리인지 지정하지 않았습니다.

해당 프로젝트가 라이브러리 인 경우, 사용하지 않는 것처럼 보이는 방법을 프로젝트 외부에서 사용할 수 있으며 제거하면 다른 프로젝트가 중단 될 수 있습니다. 라이브러리 자체가 고객에게 판매되거나 공개적으로 제공되는 경우 이러한 방법의 사용을 추적하는 것이 불가능할 수도 있습니다.

이 경우 네 가지 가능성이 있습니다.

• 메소드가 개인용 또는 패키지 개인용 인 경우 안전하게 제거 할 수 있습니다.
• 이 방법이 공용 인 경우 기능의 완전성을 위해 실제 사용 없이도 존재 여부를 정당화 할 수 있습니다. 그래도 테스트해야합니다.
• 메소드가 공개적이고 필요하지 않은 경우 메소드를 제거하면 주요 변경 사항이되고 라이브러리가 시맨틱 버전 관리를 따르는 경우 새 메이저 버전에서만 허용됩니다.
• 또는 공개 메소드는 더 이상 사용되지 않으며 나중에 제거 될 수 있습니다. 이를 통해 API 소비자는 다음 주요 버전에서 제거되기 전에 더 이상 사용되지 않는 함수에서 전환 할 수 있습니다.

먼저 코드 적용 범위 도구가 올바른지 확인하십시오.

인터페이스에 대한 참조를 통해 호출되거나 메서드가 클래스에 동적으로로드 된 경우 선택하지 않은 상황이 있습니다.

Java는 정적으로 컴파일되므로 메소드를 제거하는 것이 안전해야합니다. 죽은 코드를 제거하는 것이 좋습니다. 런타임에 시스템을 실행하는 미친 반사 시스템이있을 가능성이 있으므로 다른 개발자와 먼저 확인하고 그렇지 않으면 제거하십시오.

가장 좋은 방법은 무엇입니까? 그들을 위해 단위 테스트를 작성하거나 그들이 왜 있는지 질문합니까?

코드를 삭제하는 것이 좋습니다.

코드를 삭제할 수 없으면 @Deprecated 로 표시 하여 메소드를 제거하기 위해 어떤 주요 릴리스 를 문서화 할 수 있습니다 . 그런 다음 "나중에"삭제할 수 있습니다. 그 동안 새로운 코드를 추가해서는 안된다는 것이 분명합니다.

더 이상 사용되지 않는 방법에 대한 투자는 권장하지 않으므로 적용 범위 목표를 달성하기위한 새로운 단위 테스트는 없습니다.

이 둘의 차이점은 주로 메서드가 게시 된 인터페이스의 일부인지 여부 입니다. 게시 된 인터페이스의 일부를 임의로 삭제하면 인터페이스에 의존하는 소비자에게는 불쾌한 일이 될 수 있습니다.

나는 EclEmma와 대화 할 수 없지만 내 경험상주의해야 할 사항 중 하나는 반성입니다. 예를 들어, 텍스트 구성 파일을 사용하여 액세스 할 클래스 / 방법을 선택하는 경우 사용 / 사용하지 않는 구별이 명확하지 않을 수 있습니다 (연결된 시간에 불에 타버 렸습니다).

프로젝트가 의존성 그래프의 리프 인 경우 지원 중단 사례가 약화됩니다. 프로젝트가 라이브러리 인 경우 지원 중단 사례가 더 강력합니다.

회사에서 mono-repo를 사용하는 경우 삭제가 multi-repo 사례보다 위험이 적습니다.

l0b0 에 의해 언급 된 바와 같이 , 소스 제어에서 메소드가 이미 사용 가능한 경우, 삭제 후 메소드를 복구하는 것이 간단합니다. 그렇게해야한다고 정말로 걱정했다면 커밋을 구성하는 방법에 대해 생각해보고 삭제 된 변경 사항이 필요할 때이를 복구 할 수 있도록하십시오.

불확실성이 충분히 높으면 코드 를 삭제하지 않고 주석 처리하는 것이 좋습니다. 행복한 경로 (삭제 된 코드가 절대로 복원되지 않는)에서 추가 작업이지만 복원하기가 더 쉽습니다. 내 생각에 당신은 몇 번 그 (것)들에 의해 불에 타기까지 똑바로 삭제를 선호해야한다,이 문맥에서 "불확실성"을 평가하는 방법에 대한 통찰력을 줄 것이다.

그들이 왜 있는지 질문합니까?

지식을 포착하는 데 투자 된 시간이 반드시 낭비되는 것은 아닙니다. 필자는 코드에 대해 배운 내용을 설명하는 주석을 추가하고 커밋 한 다음 나중에 코드 (및 주석)를 삭제하여 두 단계로 제거를 수행하는 것으로 알려져 있습니다.

소스 코드를 사용하여 지식을 포착하는 방법으로 아키텍처 결정 레코드 와 유사한 것을 사용할 수도 있습니다 .

코드 적용 도구는 모든 것을 아는 것은 아닙니다. 도구가 메소드가 호출되지 않았다고 주장한다고해서 반드시 호출되지 는 않습니다 . 반영이 있으며 언어에 따라 메소드를 호출하는 다른 방법이있을 수 있습니다. C 또는 C ++에는 함수 또는 메소드 이름을 구성하는 매크로가있을 수 있으며 도구에서 호출을 보지 못할 수 있습니다. 따라서 첫 번째 단계는 다음과 같습니다. 메소드 이름과 관련 이름을 텍스트로 검색하십시오. 숙련 된 동료에게 문의하십시오. 실제로 사용 된 것을 알 수 있습니다.

확실하지 않으면 각 "미사용"메소드의 시작 부분에 assert ()를 넣으십시오. 어쩌면 전화가 올 수도 있습니다. 또는 로깅 문.

아마도 코드가 실제로 가치가있을 것입니다. 동료가 2 주 동안 작업 해 왔으며 내일 켜는 새로운 코드 일 수 있습니다. 내일 통화가 추가 될 예정이므로 오늘 전화하지 않습니다.

어쩌면 코드가 실제로는 가치있는 부분 2 : 어쩌면 코드는 문제가 발생할 수있는 매우 비싼 런타임 테스트를 수행 할 수 있습니다. 실제로 문제가 발생하는 경우에만 코드가 켜집니다. 귀중한 디버깅 도구를 삭제했을 수 있습니다.

흥미롭게도 최악의 조언은 "삭제, 커밋, 잊어 버리십시오." 가장 높은 등급입니다. (코드 리뷰? 코드 리뷰를하지 않습니까? 코드 리뷰를하지 않으면 프로그래밍은 무엇입니까?)

소프트웨어가 실행되는 환경에 따라 메소드가 호출 된 경우 로그 할 수 있습니다. 적절한 시간 내에 호출되지 않으면 메소드를 안전하게 제거 할 수 있습니다.

이 방법은 단순히 메소드를 삭제하는 것보다 더 신중한 접근 방법이며, 결함에 매우 민감한 환경에서 실행중인 경우 유용 할 수 있습니다.

Google #unreachable-code은 각 후보 후보에 대해 고유 한 식별자 를 사용하여 전용 슬랙 채널에 로그인 하며 매우 효과적임이 입증되었습니다.