Cómo encontrar código no utilizado / muerto en proyectos de Java [cerrado]

¿Qué herramientas utiliza para encontrar código no utilizado / muerto en grandes proyectos de Java? Nuestro producto ha estado en desarrollo durante algunos años, y se está volviendo muy difícil detectar manualmente el código que ya no está en uso. Sin embargo, intentamos eliminar la mayor cantidad posible de código no utilizado.

También se agradecen las sugerencias de estrategias / técnicas generales (que no sean herramientas específicas).

Editar: Tenga en cuenta que ya usamos herramientas de cobertura de código (Clover, IntelliJ), pero estas son de poca ayuda. El código muerto todavía tiene pruebas unitarias y aparece como cubierto. Supongo que una herramienta ideal identificaría grupos de código que tienen muy poco otro código dependiendo de él, lo que permite la inspección manual de documentos.

Instrumentaría el sistema en ejecución para mantener registros del uso del código y luego comenzaría a inspeccionar el código que no se usa durante meses o años.

Por ejemplo, si está interesado en clases no utilizadas, todas las clases podrían instrumentarse para iniciar sesión cuando se creen instancias. Y luego un pequeño script podría comparar estos registros con la lista completa de clases para encontrar clases no utilizadas.

Por supuesto, si va al nivel del método, debe tener en cuenta el rendimiento. Por ejemplo, los métodos solo podían registrar su primer uso. No sé cómo se hace esto mejor en Java. Lo hemos hecho en Smalltalk, que es un lenguaje dinámico y, por lo tanto, permite la modificación del código en tiempo de ejecución. Instrumentamos todos los métodos con una llamada de registro y desinstalamos el código de registro después de que un método se ha registrado por primera vez, por lo que después de algún tiempo no se producen más penalizaciones de rendimiento. Tal vez se pueda hacer algo similar en Java con banderas booleanas estáticas ...

Un complemento de Eclipse que funciona razonablemente bien es el Detector de código no utilizado .

Procesa un proyecto completo o un archivo específico y muestra varios métodos de código inactivo / inactivo, además de sugerir cambios de visibilidad (es decir, un método público que podría estar protegido o privado).

CodePro fue lanzado recientemente por Google con el proyecto Eclipse. Es gratis y altamente efectivo. El complemento tiene la función ' Buscar código muerto ' con uno / varios puntos de entrada. Funciona bastante bien

Me sorprende que ProGuard no haya sido mencionado aquí. Es uno de los productos más maduros.

ProGuard es un reductor, optimizador, ofuscador y preverificador de archivos de clase Java gratuito. Detecta y elimina clases, campos, métodos y atributos no utilizados. Optimiza el código de bytes y elimina las instrucciones no utilizadas. Cambia el nombre de las clases, campos y métodos restantes utilizando nombres cortos sin sentido. Finalmente, preverifica el código procesado para Java 6 o para Java Micro Edition.

Algunos usos de ProGuard son:

• Creación de código más compacto, para archivos de código más pequeños, transferencia más rápida a través de redes, carga más rápida y huellas de memoria más pequeñas.
• Hacer que los programas y las bibliotecas sean más difíciles de realizar ingeniería inversa.
• Listado de código muerto, por lo que puede eliminarse del código fuente.
• Retargeting y preverificación de archivos de clase existentes para Java 6 o superior, para aprovechar al máximo su carga de clase más rápida.

Aquí ejemplo para el código muerto de la lista: https://www.guardsquare.com/en/products/proguard/manual/examples#deadcode

Una cosa que se sabe que hago en Eclipse, en una sola clase, es cambiar todos sus métodos a privados y luego ver qué quejas recibo. Para los métodos que se utilizan, esto provocará errores y los devolveré al nivel de acceso más bajo que pueda. Para los métodos que no se utilizan, esto provocará advertencias sobre los métodos que no se utilizan, y luego se pueden eliminar. Y como beneficio adicional, a menudo encuentra algunos métodos públicos que pueden y deben hacerse privados.

Pero es muy manual.

Use una herramienta de cobertura de prueba para instrumentar su base de código, luego ejecute la aplicación en sí, no las pruebas.

Emma y Eclemma le darán buenos informes de qué porcentaje de las clases se ejecutan para cualquier ejecución del código.

Hemos comenzado a utilizar Find Bugs para ayudar a identificar algunos de los funk en el entorno rico en objetivos de nuestra base de código para refactorizaciones. También consideraría la Estructura 101 para identificar puntos en la arquitectura de su base de código que son demasiado complicados, para que sepa dónde están los pantanos reales.

En teoría, no puede encontrar de manera determinista el código no utilizado. Hay una prueba matemática de esto (bueno, este es un caso especial de un teorema más general). Si tienes curiosidad, busca el problema de detención.

Esto puede manifestarse en el código Java de muchas maneras:

• Carga de clases basadas en la entrada del usuario, archivos de configuración, entradas de bases de datos, etc.
• Cargando código externo;
• Pasar árboles de objetos a bibliotecas de terceros;
• etc.

Dicho esto, uso IDEA IntelliJ como mi IDE de elección y tiene amplias herramientas de análisis para encontrar dependencias entre módulos, métodos no utilizados, miembros no utilizados, clases no utilizadas, etc. Es bastante inteligente como un método privado que no se llama etiquetado sin usar, pero un método público requiere un análisis más extenso.

En Eclipse, vaya a Windows> Preferencias> Java> Compilador> Errores / Advertencias
y cámbielos a errores. Corrige todos los errores. Esta es la forma más simple. Lo bueno es que esto te permitirá limpiar el código mientras escribes.

Captura de pantalla del código de Eclipse:

IntelliJ tiene herramientas de análisis de código para detectar código que no se utiliza. Debe intentar hacer tantos campos / métodos / clases como no públicos como sea posible y eso mostrará más métodos / campos / clases no utilizados

También trataría de localizar el código duplicado como una forma de reducir el volumen del código.

Mi última sugerencia es tratar de encontrar código fuente abierto que, si se usa, simplificaría su código.

La perspectiva de división de Structure101 proporcionará una lista (y un gráfico de dependencia) de los "huérfanos" o " grupos huérfanos " de clases o paquetes que no tienen dependencias hacia o desde el clúster "principal".

DCD no es un complemento para algunos IDE, pero se puede ejecutar desde hormiga o independiente. Parece una herramienta estática y puede hacer lo que PMD y FindBugs no pueden . Voy a intentarlo.

PD Como se menciona en un comentario a continuación, el Proyecto vive ahora en GitHub .

Hay herramientas que codifican el perfil y proporcionan datos de cobertura del código. Esto le permite ver (a medida que se ejecuta el código) cuánto se llama. Puede obtener cualquiera de estas herramientas para averiguar cuánto código huérfano tiene.

• FindBugs es excelente para este tipo de cosas.
• PMD (Project Mess Detector) es otra herramienta que se puede utilizar.

Sin embargo, ninguno puede encontrar métodos estáticos públicos que no se usen en un espacio de trabajo. Si alguien conoce esa herramienta, hágamelo saber.

Herramientas de cobertura del usuario, como EMMA. Pero no es una herramienta estática (es decir, requiere ejecutar realmente la aplicación a través de pruebas de regresión y a través de todos los posibles casos de error, lo cual es, bueno, imposible :))

Aún así, EMMA es muy útil.

Las herramientas de cobertura de código, como Emma, ​​Cobertura y Clover, instrumentarán su código y registrarán qué partes se invocan ejecutando un conjunto de pruebas. Esto es muy útil y debería ser una parte integral de su proceso de desarrollo. Le ayudará a identificar qué tan bien su conjunto de pruebas cubre su código.

Sin embargo, esto no es lo mismo que identificar un código muerto real. Solo identifica el código cubierto (o no cubierto) por las pruebas. Esto puede darle falsos positivos (si sus pruebas no cubren todos los escenarios), así como falsos negativos (si sus pruebas acceden al código que en realidad nunca se usa en un escenario del mundo real).

Me imagino que la mejor manera de identificar realmente el código muerto sería instrumentar su código con una herramienta de cobertura en un entorno de ejecución en vivo y analizar la cobertura del código durante un período prolongado de tiempo.

Si está ejecutando en un entorno redundante de carga equilibrada (y si no, ¿por qué no?), Supongo que tendría sentido instrumentar solo una instancia de su aplicación y configurar su equilibrador de carga de modo que una porción aleatoria, pero pequeña, de sus usuarios se ejecutan en su instancia instrumentada. Si hace esto durante un período prolongado de tiempo (para asegurarse de haber cubierto todos los escenarios de uso del mundo real, tales variaciones estacionales), debería poder ver exactamente qué áreas de su código se accede bajo el uso del mundo real y qué partes realmente nunca se accede y, por lo tanto, el código muerto.

Nunca lo he visto personalmente, y no sé cómo se pueden usar las herramientas antes mencionadas para instrumentar y analizar el código que no se invoca a través de un conjunto de pruebas, pero estoy seguro de que sí.

Hay un proyecto Java: Detector de código muerto (DCD). Para el código fuente no parece funcionar bien, pero para el archivo .jar, es realmente bueno. Además, puedes filtrar por clase y por método.

Netbeans aquí es un complemento para el detector de código muerto de Netbeans .

Sería mejor si pudiera vincular y resaltar el código no utilizado. Puedes votar y comentar aquí: Bug 181458 - Encuentra clases públicas no utilizadas, métodos, campos

Eclipse puede mostrar / resaltar código que no se puede alcanzar. JUnit puede mostrarle la cobertura del código, pero necesitará algunas pruebas y tendrá que decidir si falta la prueba relevante o si el código realmente no se utiliza.

Encontré la herramienta de cobertura Clover que codifica los instrumentos y resalta el código que se usa y que no se usa. A diferencia de Google CodePro Analytics, también funciona para aplicaciones web (según mi experiencia y puedo ser incorrecto sobre Google CodePro).

El único inconveniente que noté es que no tiene en cuenta las interfaces Java.

Utilizo Doxygen para desarrollar un mapa de llamadas a métodos para localizar métodos que nunca se llaman. En el gráfico encontrará islas de grupos de métodos sin llamadores. Esto no funciona para las bibliotecas, ya que siempre debe comenzar desde algún punto de entrada principal.