Cómo encontrar código no utilizado / muerto en proyectos java
https://stackoverflow.com/questions/162551
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
¿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 es 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 utilizamos herramientas de cobertura de códigos (Clover, IntelliJ), pero 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.
Solución
Instalaría el sistema en ejecución para mantener registros del uso del código y luego comenzar 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 crean instancias. Y luego, una pequeña secuencia de comandos podría comparar estos registros con la lista completa de clases para encontrar clases no utilizadas.
Por supuesto, si vas al nivel de método debes tener en cuenta el rendimiento. Por ejemplo, los métodos solo podrían registrar su primer uso. No sé cómo hacerlo 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 haya registrado por primera vez, por lo tanto, 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 ...
Otros consejos
Un complemento de Eclipse que funciona razonablemente bien es Detector de código no utilizado .
Procesa un proyecto completo o un archivo específico y muestra varios métodos de código muerto / sin uso, además de sugerir cambios de visibilidad (es decir, un método público que podría estar protegido o en privado).
CodePro fue lanzado recientemente por Google con el proyecto Eclipse. Es gratis y altamente efectivo. El complemento tiene una función ' Find Dead Code ' con uno / varios puntos de entrada (s). Funciona bastante bien.
Estoy sorprendido de que ProGuard no se ha mencionado aquí. Es uno de los productos más maduros que existen.
ProGuard es un reductor de archivos de clase Java gratuito, optimizador, ofuscador, y preverificador. Detecta y elimina clases no utilizadas, campos, Métodos y atributos. Optimiza el bytecode y elimina los no utilizados. instrucciones. Renombra las clases, campos y métodos restantes utilizando nombres cortos sin sentido. Por último, preverifica el procesado. Código para Java 6 o para Java Micro Edition.
Algunos usos de ProGuard son:
- Creando 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 memoria más pequeña huellas.
- Hacer que los programas y las bibliotecas sean más difíciles de aplicar ingeniería inversa.
- Listado de código muerto, para que pueda eliminarse del código fuente.
- Reorientar y verificar previamente los archivos de clase existentes para Java 6 o superior, para aprovechar al máximo su carga de clases más rápida.
Aquí hay un ejemplo del 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 privado y luego ver qué quejas recibo. Para los métodos que se utilizan, esto provocará errores, y los devuelvo al nivel de acceso más bajo que puedo. 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 se encuentran algunos métodos públicos que pueden y deben hacerse privados.
Pero es muy manual.
Hemos empezado a utilizar Buscar errores para ayudar a identificar algunos de los errores en el código base de nuestro código base. Entorno para refactorizaciones. También consideraría Estructura 101 para identificar puntos en la arquitectura de su base de código que son demasiado complicados, para que sepa donde están los verdaderos pantanos.
En teoría, no se 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:
- Cargar clases según la entrada del usuario, los archivos de configuración, las entradas de la base de datos, etc.
- Cargando código externo;
- Pasar árboles de objetos a bibliotecas de terceros;
- etc.
Dicho esto, utilizo 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 es t call está etiquetado como no utilizado, pero un método público requiere un análisis más extenso.
En Eclipse Ir a Windows > Preferencias > Java > Compilador > Errores / Advertencias
y cambiarlos todos a errores. Arregla todos los errores. Esta es la forma más sencilla. La belleza 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. Debería intentar hacer tantos campos / métodos / clases como no públicos como sea posible y se mostrarán más métodos / campos / clases no utilizados
También intentaría ubicar el código duplicado como una forma de reducir el volumen de código.
Mi última sugerencia es tratar de encontrar un código fuente abierto que, de ser utilizado, haría su código más simple.
La Estructura101 perspectiva de segmento proporcionará una lista (y gráfico de dependencia) de cualquier " huérfanos " o " huérfano grupos " de clases o paquetes que no tienen dependencias de " main " racimo.
DCD no es un complemento para algunos IDE, pero puede ejecutarse desde ant o de forma independiente. Parece una herramienta estática y puede hacer lo que PMD y FindBugs no pueden . Lo intentaré.
P.S. Como se menciona en un comentario a continuación, el Proyecto vive ahora en GitHub .
Hay herramientas que generan un perfil de código y proporcionan datos de cobertura de código. Esto le permite ver (a medida que se ejecuta el código) cuánto se está llamando. 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 usar.
Sin embargo, ninguno de los dos puede encontrar métodos públicos estáticos que no se utilizan en un área de trabajo. Si alguien sabe de tal 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, que 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 al ejecutar 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 que está cubierto (o no está cubierto) por las pruebas. Esto le puede dar 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 con equilibrio de carga (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 forma aleatoria, pero pequeña , parte 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 a qué áreas de su código se accede con el uso en el mundo real y a 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 pueden serlo.
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í hay un complemento para Netbeans detector de código muerto .
Sería mejor si pudiera vincular y resaltar el código no utilizado. Puede votar y comentar aquí: Error 181458 - Encuentre 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 ha utilizado.
Encontré la herramienta de cobertura Clover que instruye el código 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 acerca de Google CodePro).
El único inconveniente que noté es que no tiene en cuenta las interfaces de Java.
Uso Doxygen para desarrollar un mapa de llamadas a métodos para localizar métodos a los que nunca se llama. En la gráfica encontrarás islas de grupos de métodos sin interlocutores. Esto no funciona para las bibliotecas, ya que siempre debe comenzar desde algún punto de entrada principal.
