¿Cómo puedo convencer a mis compañeros de equipo de que no debemos ignorar las advertencias del compilador?

Trabajo en un gran proyecto (más como una combinación enredada de docenas de mini proyectos que no se pueden separar fácilmente debido a una gestión de dependencia deficiente, pero esa es una discusión diferente) en Java usando eclipse. Ya hemos desactivado una serie de advertencias de la configuración del compilador y el proyecto aún tiene más de 10,000 advertencias.

Soy un gran defensor para tratar de abordar todas las advertencias, corregirlas todas si es posible, y para aquellas que se consideran y se consideran seguras, suprimirlas. (Lo mismo ocurre con mi obsesión religiosa con marcar todos los métodos implementados / anulados como @Override). Mi mayor argumento es que, en general, las advertencias lo ayudan a encontrar posibles errores durante el tiempo de compilación. Tal vez fuera 99 de cada 100 veces, las advertencias son insignificantes, pero creo que el rascarse la cabeza que ahorra por una vez que evita un error importante, todo vale la pena. (Mi otra razón es mi aparente TOC con limpieza de código).

Sin embargo, a muchos de mis compañeros de equipo no parece importarles. Ocasionalmente reparo advertencias cuando me encuentro con ellas (pero sabes que es complicado cuando tocas el código escrito por un compañero de trabajo). Ahora, con literalmente más advertencias que clases, las ventajas de las advertencias se minimizan mucho, porque cuando las advertencias son tan comunes, nadie se molestará en examinarlas todas.

¿Cómo puedo convencer a mis compañeros de equipo (o los poderes fácticos) de que las advertencias deben abordarse (o suprimirse cuando se investigan por completo)? ¿O debería convencerme de que estoy loco?

Gracias

(PD: olvidé mencionar que lo que finalmente me impulsó a publicar esta pregunta es que lamentablemente noté que estoy arreglando las advertencias más lentamente de lo que se producen)

Puedes hacer dos cosas.

1. Señale que las advertencias están ahí por una razón. Los escritores de compiladores no los incluyen porque son mezquinos. Las personas en nuestra industria son generalmente útiles. Muchas advertencias son útiles.

2. Reúna una historia de fallas espectaculares derivadas de advertencias ignoradas. Una búsqueda en la web para "Prestar atención a las advertencias del compilador" devuelve algunas anécdotas.

Su obsesión con @Overrideno es una "obsesión". Esa es una buena cosa. ¿Alguna vez escribió mal el nombre de un método?

Lectura relevante aquí . C ++, pero sigue siendo relevante. Me gusta especialmente este ejemplo (el comentario de código es mío):

int searchArray(int to_search[], int len, int to_find)
{
    int i;
    for( i = 0; i < len; ++i )
    {       
        if ( to_search[i] == to_find )
        {
            return i;
        }
    }
    // should be returning designated 'not found' value (0, -1, etc)
}

Muchas veces, una advertencia significará la diferencia entre el bloqueo de la aplicación con un error que realmente lo ayudará a rastrear un error de diseño y corregirlo (como la conversión de texto segura ) o la aplicación hace suposiciones y luego se comporta de manera incorrecta o de manera errónea (que sería el caso con la conversión de texto insegura ). Del mismo modo, también señalan el código cruft o dead que se puede eliminar (bloques de código inalcanzables, variables no utilizadas), que se puede considerar optimización de código o casos no contabilizados que aparecerán en las pruebas, como el ejemplo anterior para C ++. Tenga en cuenta que este ejemplo produce un error en tiempo de compilación en Java.

Por lo tanto, corregir las advertencias tiene (al menos) varias ventajas para la administración:

1. Menos posibilidades de que el código se comporte de manera inadecuada con los datos ingresados ​​por el usuario que, para los superiores preocupados por la imagen de la empresa y cómo maneja los datos de sus clientes, debería ser un gran problema (tm). Bloquear para evitar que un usuario haga algo tonto es mejor que no hacerlo y dejar que lo hagan.
2. Si quieren reorganizar al personal, las personas pueden entrar en una base de código libre de advertencias (y no asustarse ni quejarse tanto ...). Tal vez esto reducirá la cantidad de refunfuños u opiniones sobre la capacidad de mantenimiento o la calidad de la contribución del Equipo X al Proyecto Y.
3. La optimización del código al eliminar las advertencias del compilador, sin proporcionar mejoras significativas en el tiempo de ejecución, mejorará numerosos puntajes en lo que respecta a las pruebas:
   • Cualquier puntaje de cobertura de código probablemente aumentará.
   • Los límites de prueba y los casos de prueba inválidos probablemente tendrán éxito con mayor frecuencia (debido a la conversión de texto segura mencionada anteriormente , entre otras cosas).
   • Cuando falla un caso de prueba, no tiene que pensar si se debe a una de las advertencias del compilador en ese archivo fuente.
   • Es fácilmente discutible que cero advertencias del compilador es mejor que miles. Sin advertencias ni errores se habla de la calidad del código, por lo que puede argumentar que la calidad del código mejora las menos advertencias que hay.
4. Si no tiene advertencias del compilador, y se introducen una o más, es mucho más fácil saber quién hizo que aparecieran en la base de código. Si tiene una política de "no advertencias", ¿eso podría ayudarlos a identificar a las personas que no están haciendo su trabajo correctamente, tal vez? Escribir código no se trata solo de hacer que algo funcione, se trata de hacerlo funcionar bien .

Tenga en cuenta que todavía soy un desarrollador junior que sabe poco acerca de la gestión de proyectos, por lo que si he dicho algo mal, corrija mi pensamiento y deme la oportunidad de editar antes de desestimar su existencia :)

He trabajado en un proyecto con características similares en el pasado. Este en particular fue escrito originalmente en Java 1.4. Una vez que salió Java 5 con genéricos, uno puede imaginar la cantidad de advertencias lanzadas por el compilador para cada uso de la API de Colecciones.

Habría tomado bastante tiempo deshacerse de todas las advertencias, comenzando a usar genéricos. Ese es un factor que debe tenerse en cuenta, pero cuando tiene que convencer a alguien (especialmente a su gerente) de que necesita reparación, necesitará datos duros, como

el tiempo dedicado a errores en código heredado o no compatible (el estándar es el estándar de codificación de su proyecto) que podría haberse evitado.

Podría seguir presentando una factura que demuestre cómo está perdiendo tiempo y dinero al ignorar "ciertas" advertencias, y alguien tendrá la idea. La parte clave es que no vale la pena mirar todas las advertencias, al menos no de inmediato; en palabras más simples, deberá establecer la prioridad de las advertencias que deben abordarse de inmediato. Para empezar, considere los pertinentes a los errores que está viendo en su proyecto.

También puede tomar notas en el rastreador de errores, cuando corrige los errores, de que dicho error podría haberse evitado al no ignorar una advertencia (o tal vez ejecutando PMD o FindBugs si tiene un CI o un sistema de compilación). Siempre que haya una cantidad suficiente de errores que puedan solucionarse atendiendo a las advertencias del compilador, su punto sobre mirar las advertencias del compilador sería válido. De lo contrario, es una decisión comercial y, por lo general, no vale la pena gastar el tiempo en luchar en esta batalla.

Si tiene éxito y su equipo decide observar las advertencias, debe adoptar un enfoque gradual. Nadie puede y hará 10000 advertencias al mismo tiempo. Por lo tanto, puede seleccionar los más importantes (aquellos que son errores con alta probabilidad) y deshabilitar los menos significativos. Si se arreglan, aumente el nivel de advertencia nuevamente. Además, puede comenzar con FindBugs, que advierte sobre el código que casi siempre es un error.

Estoy totalmente de acuerdo con usted, es una buena práctica limpiar las advertencias de compilación lo más posible. Usted mencionó que su equipo está utilizando Eclipse como herramienta de desarrollo. Eclipse es una muy buena herramienta para ayudarlo a limpiar el código y lograr la consistencia del estilo del código.

1. defina 'Guardar acción' para cada proyecto Java, como formatear código, variables locales no utilizadas, organizar las importaciones (creo que nadie tiene objeciones sobre este tipo de limpieza).
2. definir opciones de compilación específicas del proyecto para cada proyecto. Por ejemplo, el nivel de compilación (si su código necesita ser compatible con 1.4 para limpiar las advertencias relacionadas con el genérico), la asignación no tiene efecto (por ejemplo, 'x = x') y así sucesivamente. Usted y su compañero de equipo pueden llegar a un acuerdo para esos artículos, y Eclipse los informará como 'Error' en su fase de desarrollo después de que haya aceptado el error de compilación.

Eclipse creará algunos archivos de propiedades para esas preferencias en la carpeta .settings, puede copiarlos en otros proyectos Java y registrarlos en SCM como parte del código fuente.

Puede consultar el código de Eclipse para ver cómo lo hacen los desarrolladores de Eclipse.

Tiene dos formas de deshacerse de todas las advertencias (y estoy de acuerdo en que puede ocultar un error sutil):

1. Convenza a todo el equipo de que esto es lo mejor que puede hacer y pídales que lo arreglen.
2. Convence a tu jefe de que esto es lo mejor que puedes hacer y haz que sea obligatorio. Entonces necesitan arreglarlo.

Creo que 1 ya no es factible en su caso. Además, esto probablemente tomará tanto tiempo debido a la cantidad de advertencias que esto se mostrará en la salida de productividad, por lo que la administración deberá saberlo de todos modos.

Por lo tanto, mi sugerencia es: tómalo con el jefe, convéncelo de que es una bomba de tiempo y haz que sea una política oficial.

Solo les diría que la mayoría de estas son advertencias insignificantes y es esencial que las eliminemos de la lista. ¡Para que no perdamos la verdadera advertencia significativa en la multitud, como sucede!

Necesitarás mucha paciencia para tratar de convencerlos, eliminar las advertencias cuando hagas una programación en pareja ayudará a otros a adoptar el hábito. Sugiérales que lean el artículo 24 de Java efectivo: elimine las advertencias no verificadas (para la colección genérica). Y probablemente ignore muchos casos en que las personas no siguen sus consejos;)

Un enfoque efectivo aquí sería configurar un servidor de Integración Continua que construya automáticamente el proyecto y ejecute las pruebas cada vez que alguien registre el código. Si aún no está usando esto, debería hacerlo, y no es muy difícil convencer a otros de los beneficios de hacerlo.

1. Convencer a los líderes de gestión / equipo de los beneficios de hacer esto (evitar que se implementen compilaciones erróneas, encontrar errores temprano, especialmente aquellos que afectan accidentalmente otras partes del software, mantener pruebas de regresión, pruebas tempranas y frecuentes, etc.)

2. Instale el servidor CI con todas las pruebas aprobadas (si no tiene pruebas, escriba una rápida que pase, para que todos vean que es verde).

3. Configure correos electrónicos u otras notificaciones sobre el estado de cada compilación. Aquí es importante incluir quién registró el código, cuál fue el cambio (o un enlace a la confirmación) y el estado + salida de la compilación. Este es un paso importante, ya que causa visibilidad en todo el equipo tanto para los éxitos como para los fracasos.

4. Actualice el servidor de CI para que las pruebas fallen si hay advertencias. Esto será visto por la gerencia y los líderes del equipo como un aumento de la disciplina del equipo de manera sistemática, y nadie quiere ser responsable de todos los correos electrónicos fallidos que se envían.

5. (opcional) sea agradable y geek con esto, agregando algunos paneles visibles, lámparas de lava, luces intermitentes, etc. para indicar el estado de la construcción y quién la rompió / arregló.