programing

Java 프로젝트에서 미사용/데드 코드를 찾는 방법

coolbiz 2022. 7. 15. 23:02
반응형

Java 프로젝트에서 미사용/데드 코드를 찾는 방법

대규모 Java 프로젝트에서 사용되지 않거나 비활성 코드를 찾기 위해 어떤 도구를 사용합니까?우리 제품은 몇 년 동안 개발되어 왔고, 더 이상 사용되지 않는 코드를 수동으로 감지하는 것이 매우 어려워지고 있습니다.단, 사용하지 않는 코드를 가능한 한 많이 삭제하려고 합니다.

일반적인 전략/기술(특정 툴 이외)에 대한 제안도 감사하게 생각합니다.

편집: 이미 코드 커버리지 툴(Clover, IntelliJ)을 사용하고 있습니다만, 이러한 툴은 거의 도움이 되지 않습니다.데드코드는 아직 유닛테스트가 진행되어 커버된 상태로 표시된다.다른 코드가 거의 없는 코드 클러스터를 식별하여 문서 수동 검사를 가능하게 하는 것이 이상적인 도구라고 생각합니다.

Eclipse 플러그인은 사용하지 않는 코드 디텍터입니다.

프로젝트 전체 또는 특정 파일을 처리하여 다양한 미사용/데드 코드 메서드를 표시하고 가시성 변경(보호 또는 비공개 가능한 퍼블릭 메서드)을 제안합니다.

코드 프로는 최근 이클립스 프로젝트와 함께 구글에 의해 출시되었습니다.그것은 무료이고 매우 효과적이다.플러그인에는 하나 이상의 진입점이 있는 '데드 코드 찾기' 기능이 있습니다.꽤 잘 작동한다.

실행 중인 시스템에 코드 사용 로그를 기록하고 몇 개월 또는 몇 년 동안 사용되지 않은 코드를 검사합니다.

예를 들어 사용하지 않는 클래스에 관심이 있는 경우 모든 클래스가 인스턴스가 생성될 때 로그에 기록되도록 계측할 수 있습니다.그런 다음 작은 스크립트에서 이러한 로그를 전체 클래스 목록과 비교하여 사용되지 않는 클래스를 찾을 수 있습니다.

물론 메서드 레벨로 진행된다면 퍼포먼스를 염두에 두어야 합니다.예를 들어 메서드는 첫 번째 사용만 기록할 수 있습니다.자바에서 이게 어떻게 최선인지 모르겠어요.우리는 이것을 동적 언어인 Smalltalk에서 수행했고, 따라서 런타임에 코드를 수정할 수 있습니다.로깅 콜을 사용하여 모든 메서드를 계측하고 메서드가 처음 로깅된 후 로깅 코드를 제거합니다.따라서 시간이 지나면 성능 저하가 발생하지 않습니다.Java에서도 정적 부울 플래그를 사용하여 비슷한 작업을 수행할 수 있습니다.

프로가드가 여기에 언급되지 않았다니 놀랍군요.가장 성숙한 제품 중 하나입니다.

ProGuard는 무료 Java 클래스 파일 축소기, 최적화기, 난독화기 및 프리 검증기입니다.사용되지 않는 클래스, 필드, 메서드 및 Atribute를 검출하여 삭제합니다.바이트 코드를 최적화하고 사용되지 않는 명령을 제거합니다.나머지 클래스, 필드 및 메서드는 짧은 의미 없는 이름을 사용하여 이름을 변경합니다.마지막으로 Java 6 또는 Java Micro Edition의 처리된 코드를 미리 검증합니다.

ProGuard의 용도는 다음과 같습니다.

  • 보다 콤팩트한 코드 작성, 소규모 코드 아카이브, 네트워크 간 전송의 고속화, 로딩의 고속화, 메모리의 공간 절약.
  • 프로그램과 라이브러리를 리버스 엔지니어링하기 어렵게 만듭니다.
  • 소스 코드에서 삭제할 수 있도록 데드 코드를 나열하고 있습니다.
  • Java 6 이상용 기존 클래스 파일의 대상을 재설정하고 사전 검증하여 보다 빠른 클래스 로드를 최대한 활용합니다.

리스트 데드 코드의 예를 다음에 나타냅니다.https://www.guardsquare.com/en/products/proguard/manual/examples#deadcode

제가 이클립스에서 한 수업에서 했던 일 중 하나는 모든 방법을 비공개로 바꾸고 어떤 불만이 오는지 보는 것입니다.사용되는 메서드의 경우 오류가 발생하여 가능한 한 낮은 접근 수준으로 되돌립니다.사용되지 않는 메서드의 경우 사용되지 않는 메서드에 대한 경고가 발생하고 이러한 메서드는 삭제될 수 있습니다.그리고 보너스로, 당신은 종종 비공개로 만들어질 수 있는 몇 가지 공개 방법을 찾을 수 있다.

하지만 매우 수동적입니다.

테스트 적용 범위 도구를 사용하여 코드베이스를 계측한 다음 테스트가 아닌 응용 프로그램 자체를 실행합니다.

EmmaEclemma는 주어진 코드 실행에서 실행되는 클래스의 비율을 보고합니다.

Find Bugs를 사용하여 코드베이스의 리팩터링을 위한 타겟이 풍부한 환경에서 펑크를 식별하기 시작했습니다.또한 코드베이스 아키텍처에서 너무 복잡한 스팟을 식별하기 위해 Structure 101을 고려할 수 있습니다.그러면 실제 늪이 어디에 있는지 알 수 있습니다.

이론적으로는 사용하지 않는 코드를 결정적으로 찾을 수 없습니다.이것에 대한 수학적 증거가 있다(글쎄, 이것은 더 일반적인 정리의 특별한 경우이다).궁금하면 정지 문제를 찾아보세요.

이는 Java 코드에서 여러 가지 방법으로 나타날 수 있습니다.

  • 사용자 입력, 구성 파일, 데이터베이스 엔트리 등에 기반한 클래스 로드
  • 외부 코드 로드 중;
  • 오브젝트 트리를 서드파티 라이브러리에 전달한다.
  • 기타.

즉, IDEA IntelliJ를 선택한 IDE로 사용하고 있으며 모듈, 미사용 메서드, 미사용 멤버, 미사용 클래스 등을 검출하기 위한 광범위한 분석 툴을 갖추고 있습니다.호출되지 않은 개인 메서드와 마찬가지로 매우 지능적이지만, 공용 메서드는 더 광범위한 분석이 필요합니다.

[ ]> [ Preferences ]> [ ]> [ Java ]> [ Eclipse Goto Windows ]> [ Errors / ]> [ Urrors ]> [ ] ] 。
모두 에러로 변경해 주세요.모든 오류를 수정합니다.이것이 가장 간단한 방법입니다.이렇게 하면 코드를 쓸 때 정리할 수 있다는 것이 장점입니다.

스크린샷 이클립스 코드:

여기에 이미지 설명 입력

IntelliJ에는 사용되지 않는 코드를 검출하기 위한 코드 분석 도구가 있습니다.가능한 한 많은 필드/메서드/클래스를 공개하지 않도록 해야 합니다.그러면 사용되지 않는 메서드/필드/클래스가 더 많이 표시됩니다.

또한 코드 볼륨을 줄이기 위한 방법으로 중복된 코드를 찾도록 하겠습니다.

마지막으로 제안하는 것은 오픈 소스 코드를 찾는 것입니다.이 코드를 사용하면 당신의 코드를 쉽게 만들 수 있습니다.

Structure101 슬라이스 관점에서는 "메인" 클러스터와의 의존관계가 없는 클래스 또는 패키지의 "orphan" 또는 "orphan 그룹" 목록(및 의존관계 그래프)이 표시됩니다.

DCD는 일부 IDE용 플러그인은 아니지만 ant 또는 스탠드아론에서 실행할 수 있습니다.이것은 정적인 도구처럼 보이며 PMD와 FindBugs가 할 없는 을 할 수 있습니다.해보겠습니다.

추신: 아래 댓글에서 언급했듯이, 프로젝트는 현재 GitHub에 존재합니다.

코드를 프로파일링하고 코드 적용 범위 데이터를 제공하는 도구가 있습니다.이를 통해 (코드 실행 시) 호출된 패킷의 양을 확인할 수 있습니다.이러한 툴 중 하나를 사용하여 고아 코드가 얼마나 있는지 확인할 수 있습니다.

  • FindBugs는 이런 종류의 일에 매우 적합합니다.
  • PMD(Project Mess Detector)도 사용할 수 있는 도구입니다.

그러나 워크스페이스에서 사용되지 않는 공용 정적 메서드는 둘 다 찾을 수 없습니다.그런 툴에 대해 아는 사람이 있으면 알려주세요.

사용자 커버리지 툴(EMA 등)입니다.다만, 스태틱 툴은 아닙니다(즉, 회귀 테스트나 가능한 모든 에러 케이스에 의해서 애플리케이션을 실제로 실행할 필요가 있습니다.이러한 툴은 불가능합니다:)

그래도 Emma는 매우 유용합니다.

Emma, Cobertura, Clober 등의 코드 커버리지 툴은 코드를 계측하여 테스트 스위트를 실행하여 어떤 부분이 호출되는지 기록합니다.이는 매우 유용하며 개발 프로세스의 필수 요소입니다.테스트 스위트가 코드를 어느 정도 커버하고 있는지를 특정하는 데 도움이 됩니다.

단, 이것은 실제 데드코드를 식별하는 것과는 다릅니다.테스트의 대상이 되는(또는 대상이 되지 않는) 코드만 식별합니다.이를 통해 false positive(테스트가 모든 시나리오를 커버하지 않는 경우)와 false negative(테스트가 실제 시나리오에서는 사용되지 않는 코드에 액세스 하는 경우)를 얻을 수 있습니다.

실제로 데드 코드를 식별하는 가장 좋은 방법은 가동 중인 환경에서 커버리지 도구를 사용하여 코드를 계측하고 장기간에 걸쳐 코드 커버리지를 분석하는 것입니다.

로드 밸런싱된 다중 환경에서 실행 중인 경우(그렇지 않은 경우 왜 안 되는 경우), 애플리케이션의 인스턴스를 하나만 계측하고 사용자 중 랜덤하지만 작은 부분이 계측된 인스턴스에서 실행되도록 로드 밸런서를 구성하는 것이 합리적이라고 생각합니다.장기간에 걸쳐 이 작업을 실시하면(모든 실제 사용 시나리오(이러한 계절에 따른 변동) 코드의 어느 영역에 실제로 액세스 할 수 있는지, 또 실제로 액세스 할 수 없는 부분, 즉 데드 코드를 정확하게 확인할 수 있습니다.

저는 개인적으로 이 작업이 완료되는 것을 본 적이 없습니다.또한 테스트 스위트를 통해 호출되지 않는 코드를 계측하고 분석하는 데 전술한 도구를 어떻게 사용할 수 있는지 모르겠습니다.다만, 그렇게 할 수 있다고 확신합니다.

Java 프로젝트 - DCD(Dead Code Detector)가 있습니다.소스 코드에서는 잘 작동하지 않는 것처럼 보이지만 .jar 파일에서는 매우 좋습니다.또한 클래스 및 메서드로 필터링할 수 있습니다.

여기 Netbeans는 Netbeans 데드 코드 디텍터용 플러그인입니다.

사용하지 않는 코드에 링크하여 강조 표시할 수 있으면 좋겠습니다.Bug 181458 - 사용되지 않는 퍼블릭 클래스, 메서드, 필드 검색

이클립스는 도달할 수 없는 코드를 표시하거나 강조 표시할 수 있습니다.JUnit은 코드 커버리지를 보여줄 수 있지만, 몇 가지 테스트가 필요하며 관련 테스트가 누락되었는지 또는 코드가 실제로 사용되지 않았는지 판단해야 합니다.

사용 코드와 사용하지 않는 코드를 계측하고 강조 표시하는 Clover 커버리지 툴을 찾았습니다.Google CodePro Analytics와 달리 WebApplications에서도 사용할 수 있습니다(내 경험에 따르면 Google CodePro에 대해 잘못 알고 있을 수 있습니다).

단점은 Java 인터페이스를 고려하지 않는다는 것입니다.

Doxygen을 사용하여 호출되지 않은 메서드를 찾기 위한 메서드콜 맵을 만듭니다그래프에는 발신자가 없는 메서드클러스터의 섬이 표시됩니다.라이브러리에서는 항상 주 진입점부터 시작해야 하므로 이 방법은 작동하지 않습니다.

언급URL : https://stackoverflow.com/questions/162551/how-to-find-unused-dead-code-in-java-projects

반응형