La cobertura del código destaca los métodos no utilizados: ¿qué debo hacer?

Se me ha encomendado la tarea de aumentar la cobertura del código de un proyecto Java existente.

Noté que la herramienta de cobertura de código ( EclEmma ) ha resaltado algunos métodos que nunca se llaman desde ningún lugar.

Mi reacción inicial no es escribir pruebas unitarias para estos métodos, sino resaltarlas ante mi gerente / equipo de línea y preguntar por qué estas funciones están ahí para empezar.

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

1. Eliminar.
2. Cometer.
3. Olvidar.

Razón fundamental o base lógica:

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 momento, pero eso ya no existe, por lo que el código debería desaparecer.
2. El control de versiones asegura que, en mi experiencia, un evento único y raro en el que alguien venga más tarde en busca de ese código, se pueda recuperar.
3. Como efecto secundario, mejora instantáneamente la cobertura del código sin hacer nada (a menos que se pruebe el código muerto, lo que rara vez es el caso).

Advertencia de los comentarios: la respuesta original suponía que había verificado a fondo que el código está, sin duda, muerto. Los IDE son falibles, y hay varias formas en que el código que parece muerto podría llamarse de hecho. 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 no se utilizan realmente. 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 en sí 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 privados del paquete, se pueden eliminar de forma segura.
• Si los métodos son públicos, su presencia puede estar justificada incluso sin un uso real, para completar las características. Sin embargo, deberían ser probados.
• Si los métodos son públicos e innecesarios, eliminarlos será un cambio radical y si la biblioteca sigue las 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 les da algo de tiempo a los consumidores de API para pasar de las funciones obsoletas antes de que se eliminen en la próxima versión principal.

Primero verifique que su herramienta de cobertura de código sea correcta.

He tenido situaciones en las que no han captado los métodos que se llaman 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 el código muerto siempre es bueno. Existe cierta probabilidad de que haya algún sistema de reflexión loco que los ejecute en tiempo de ejecución, así que verifique primero con otros desarrolladores, pero de lo contrario 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 algo bueno.

Cuando no puede eliminar el código, ciertamente puede marcarlo como @Deprecated , documentando a qué versión principal está apuntando para eliminar el método. Luego puede eliminarlo "más tarde". Mientras tanto, estará 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 solo para alcanzar los objetivos de cobertura.

La diferencia entre los dos es principalmente si los métodos son o no parte de la interfaz publicada . Eliminar arbitrariamente 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, usa archivos de configuración de texto para elegir a qué clases / métodos acceder, la distinción utilizada / no utilizada puede no ser obvia (eso me ha quemado un par de veces).

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-repos , entonces eliminar es un riesgo menor que en el caso de múltiples repos.

Como se señala en 10b0 , si los métodos ya están disponibles en el control de origen, recuperarlos después de la eliminación es un ejercicio sencillo. Si estaba realmente preocupado por la necesidad de hacer eso, piense cómo organizar sus confirmaciones 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 el camino feliz (donde el código eliminado nunca se restaura), pero hace que sea más fácil de restaurar. Supongo que debería preferir una eliminación directa hasta que se haya quemado un par de veces, lo que le dará algunas ideas sobre cómo evaluar la "incertidumbre" en este contexto.

pregunta por qué están allí?

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

También podría usar algo análogo a los registros de decisiones arquitectónicas como una forma de capturar la historia con el código fuente.

Una herramienta de cobertura de código no lo sabe todo, todo lo ve. El hecho de que su herramienta afirme que el método no se llama, eso no significa que no se llame. Hay reflexión, y dependiendo del idioma puede haber otras formas de llamar al método. En C o C ++ puede haber macros que construyen nombres de funciones o métodos, y es posible que la herramienta no vea la llamada. Entonces, el primer paso sería: hacer una búsqueda textual del nombre del método y de los nombres relacionados. Pregunta a colegas con experiencia. Puede encontrar que realmente se usa.

Si no está seguro, coloque una afirmación () al comienzo de cada método "no utilizado". Tal vez se llama. O una declaración de registro.

Quizás el código sea realmente valioso. Puede ser un nuevo código en el que un colega ha estado trabajando durante dos semanas, y que él o ella iba a activar mañana. No se llama hoy porque la llamada se agregará mañana.

Tal vez el código sea realmente valioso parte 2: el código puede estar realizando algunas pruebas de tiempo de ejecución muy costosas que podrían encontrar que las cosas van mal El código solo se activa si las cosas realmente salen mal. Puede estar eliminando una valiosa herramienta de depuración.

Curiosamente, el peor consejo posible "Eliminar. Comprometerse. Olvidar". es el mejor valorado (¿Revisiones de código? ¿No haces revisiones de código? ¿Qué demonios estás programando si no haces revisiones de código?)

Dependiendo del entorno en el que se ejecute el software, puede iniciar sesión si alguna vez se llama al método. Si no se llama dentro de un período de tiempo adecuado, entonces el método se puede eliminar de forma segura.

Este es un enfoque más cauteloso que simplemente eliminar el método, y puede ser útil si está ejecutando en un entorno altamente sensible a fallas.

Iniciamos sesión en un #unreachable-codecanal dedicado dedicado con un identificador único para cada candidato para la eliminación, y se demostró que es bastante efectivo.