La cobertura del código resalta los métodos no utilizados. ¿Qué debo hacer?

1. Eliminar.
2. Cometer.
3. Olvídate.

Justificación:

1. El código muerto está muerto. Por su propia descripción no tiene ningún propósito. Puede que haya tenido un propósito en un punto, pero eso ya no existe, por lo que el código debería desaparecer.
2. El control de versión garantiza que, en mi caso, el evento único raro que alguien viene más tarde en busca de ese código, se puede recuperar.
3. Como efecto secundario, instantáneamente mejora la cobertura del código sin hacer nada (a menos que se pruebe el código muerto, que rara vez es el caso).

Advertencia de los comentarios: la respuesta original supuso que usted había verificado a fondo que el código está, más allá de toda duda, muerto. Los IDE son falibles, y hay varias maneras en las que el código que parece muerto podría, de hecho, ser llamado. Traiga un experto a menos que esté absolutamente seguro.

Todas las demás respuestas se basan en el supuesto de que los métodos en cuestión realmente no se utilizan. Sin embargo, la pregunta no especificó si este proyecto es autónomo o una biblioteca de algún tipo.

Si el proyecto en cuestión es una biblioteca, los métodos aparentemente no utilizados pueden usarse fuera del proyecto y eliminarlos rompería esos otros proyectos. Si la biblioteca se vende a los clientes o se pone a disposición del público, puede ser incluso imposible rastrear el uso de estos métodos.

En este caso, hay cuatro posibilidades:

• Si los métodos son privados o de paquetes privados, se pueden eliminar de forma segura.
• Si los métodos son públicos, su presencia puede estar justificada incluso sin uso real, para completar la funcionalidad. Sin embargo, deberían ser probados.
• Si los métodos son públicos e innecesarios, eliminarlos será un cambio importante y si la biblioteca sigue versiones semánticas , esto solo se permite en una nueva versión principal.
• Alternativamente, los métodos públicos también pueden ser desaprobados y eliminados más tarde. Esto da a los consumidores de API algo de tiempo para pasar de las funciones en desuso antes de que se eliminen en la próxima versión principal.

Primero verifica que la herramienta de cobertura de tu código sea correcta.

He tenido situaciones en las que no han detectado los métodos a los que se llama a través de referencias a la interfaz, o si la clase se carga dinámicamente en algún lugar.

Como Java está compilado estáticamente, debería ser bastante seguro eliminar los métodos. Eliminar código muerto siempre es bueno. Existe cierta probabilidad de que exista algún sistema de reflexión loco que los ejecute en tiempo de ejecución, así que consulte primero con otros desarrolladores, pero elimínelos.

  

¿Cuál sería el mejor enfoque? Escriba pruebas unitarias para ellos, o pregunte por qué están allí?

Eliminar código es una buena cosa.

Cuando no puede eliminar el código, puede marcarlo como @Deprecated , que documenta la versión principal que está seleccionando para eliminar el método. Luego puedes borrarlo "más tarde". Mientras tanto, quedará claro que no se debe agregar ningún código nuevo que dependa de él.

No recomendaría invertir en métodos obsoletos, por lo que no hay nuevas pruebas unitarias para alcanzar los objetivos de cobertura.

La diferencia entre los dos es principalmente si los métodos son parte o no de la interfaz publicada . La eliminación arbitraria de partes de la interfaz publicada puede ser una sorpresa desagradable para los consumidores que dependían de la interfaz.

No puedo hablar con EclEmma, pero según mi experiencia, una de las cosas de las que debes tener cuidado es la reflexión. Si, por ejemplo, utiliza archivos de configuración de texto para elegir a qué clases / métodos acceder, la distinción utilizada / no utilizada puede no ser obvia (me han quemado por un tiempo).

Si su proyecto es una hoja en el gráfico de dependencia, entonces el caso de desaprobación se debilita. Si su proyecto es una biblioteca, entonces el caso de desaprobación es más fuerte.

Si su empresa utiliza un mono-repo , eliminar es un riesgo menor que en el caso de múltiples repositorios.

Como se señala en l0b0 , si los métodos ya están disponibles en el control de origen, recuperarlos después de la eliminación es un proceso sencillo. ejercicio. Si estaba realmente preocupado por la necesidad de hacerlo, piense en cómo organizar sus compromisos para que pueda recuperar los cambios eliminados si los necesita.

Si la incertidumbre es lo suficientemente alta, podría considerar comentar el código , en lugar de eliminarlo. Es un trabajo extra en la ruta feliz (donde el código eliminado nunca se restaura), pero hace que sea más fácil de restaurar. Supongo que deberías preferir una eliminación directa hasta que te hayas quemado un par de veces, lo que te dará una idea de cómo evaluar la "incertidumbre" en este contexto.

  

pregunta por qué están ahí?

El tiempo invertido en capturar la historia no se pierde necesariamente. Se sabe que realizo una eliminación en dos pasos: primero, agregando y confirmando un comentario que explique lo que hemos aprendido sobre el código, y luego borrando el código (y el comentario).

También puede usar algo análogo a registros de decisiones arquitectónicas como una forma de capturar La tradición con el código fuente.

Una herramienta de cobertura de código no es omnisciente, todo lo ve. El hecho de que su herramienta diga que no se llama al método, no significa que no se llame a . Hay reflexión y, dependiendo del idioma, puede haber otras formas de llamar al método. En C o C ++ puede haber macros que construyan nombres de funciones o métodos, y la herramienta podría no ver la llamada. Entonces, el primer paso sería: realizar una búsqueda textual del nombre del método y de los nombres relacionados. Pregunte a colegas con experiencia. Usted puede encontrar que realmente se utiliza.