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

47

Trabajo en un gran proyecto (más como una combinación enmarañada de docenas de mini proyectos que no se pueden separar fácilmente debido a una mala gestión de la dependencia, 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 de tratar de abordar todas las advertencias, corregirlas todas si es posible, y para aquellas que se consideran y consideran seguras, elimínelas. (Lo mismo ocurre con mi obsesión religiosa con marcar todo el método implementado / anulado como @Override). Mi mayor argumento es que, en general, las advertencias lo ayudan a encontrar errores potenciales durante el tiempo de compilación. Tal vez fuera 99 de 100 veces, las advertencias son insignificantes, pero creo que el rascarse la cabeza que se guarda por una vez que previene un error importante, 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 corrijo advertencias cuando las encuentro (pero sabes que es complicado cuando tocas un 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 mirarlas todas.

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

Gracias

(P.S. Olvidé mencionar que lo que finalmente me impulsó a publicar esta pregunta es que, lamentablemente, noté que estoy corrigiendo las advertencias más lentamente de lo que se producen)

    
pregunta 21.07.2011 - 08:24

9 respuestas

35

Puedes hacer dos cosas.

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

  2. Recopile un historial de fallas espectaculares que surgen de advertencias ignoradas. Una búsqueda en la web de "Preste atención a las advertencias del compilador" devuelve algunas anécdotas.

Tu obsesión con @Override no es una "obsesión". Esa es una buena cosa. ¿Alguna vez ha escrito mal el nombre de un método?

    
respondido por el Ray Toal 21.07.2011 - 08:32
11

Lectura relevante aquí . C ++, pero sigue siendo relevante. Me gusta especialmente este ejemplo (el comentario del 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)
}

La mayoría de las veces, una advertencia significará la diferencia entre un error de la aplicación y un error que realmente lo ayudará a localizar un defecto de diseño y solucionarlo (como el encasillado safe ) o la la aplicación hace suposiciones y luego se comporta de manera incorrecta o errónea (como sería el caso de encasillado inseguro ). De manera similar, también señalan el código cruzado o muerto que se puede eliminar (bloques de código inalcanzables, variables no utilizadas), que pueden considerarse optimización de código, o casos no contabilizados que se mostrará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 advertencias tiene (al menos) varias ventajas para la administración:

  1. Menos posibilidades de que el código se comporte de manera incorrecta con los datos ingresados por el usuario, lo que, para los más importantes, se preocupa por la imagen de la compañía y cómo maneja los datos de sus clientes, debería ser un gran acuerdo (tm). Chocar para evitar que un usuario haga algo tonto es mejor que no chocar y dejar que lo haga.
  2. Si quieren reorganizar al personal, las personas pueden ingresar a una base de código sin advertencias (y no asustarse ni quejarse tanto ...). Tal vez esto reduzca la cantidad de quejas o las 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 mediante la eliminación de las advertencias del compilador, aunque no ofrece mejoras significativas en el tiempo de ejecución, mejorará numerosas puntuaciones cuando se trata de pruebas:
    • Es probable que aumente el puntaje de cobertura del código.
    • Es probable que los casos de prueba de límites e inválidos de prueba tengan éxito con más frecuencia (debido a la anterior tipografía de caja fuerte , entre otras cosas).
    • Cuando un caso de prueba falla, 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. Ninguna advertencia o error habla sobre la calidad del código, por lo que puede argumentar que la calidad del código mejora a medida que hay menos advertencias.
  4. Si no tiene advertencias de compilación, y se presentan una o más, es mucho más fácil saber quién causó que aparezcan en la base de código. Si tiene una política de "no advertencias", ¿eso les ayudaría a identificar a las personas que no están haciendo su trabajo correctamente, tal vez? Escribir código no solo se trata de hacer que algo funcione, se trata de hacerlo funcionar bien .

Tenga en cuenta que todavía soy solo un desarrollador junior que sabe poco acerca de la gestión de proyectos, así que si he dicho algo incorrecto, corrija mi pensamiento y dame la oportunidad de editar antes de que me rechacen de la existencia:)

    
respondido por el darvids0n 21.07.2011 - 09:26
7

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 emitidas por el compilador para cada uso de la API de colecciones.

Habría tardado bastante en deshacerse de todas las advertencias, al comenzar a usar genéricos. Ese es un factor que debe tenerse en cuenta, pero cuando tenga que convencer a alguien (especialmente a su administrador) de que necesita una solución, necesitará datos duros, como

  

el tiempo dedicado a los errores en el código de compatibilidad heredado o no estándar (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 todas las advertencias son dignas de ver, 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 arregle errores, que dicho error podría haberse evitado al no ignorar una advertencia (o quizás al ejecutar PMD o FindBugs si tiene un CI o un sistema de compilación). Siempre que haya un número suficiente de errores que puedan solucionarse prestando atención a las advertencias del compilador, su punto de vista de las advertencias del compilador sería válido. De lo contrario, es una decisión de negocios y, por lo general, no vale la pena gastar tiempo en luchar en esta batalla.

    
respondido por el Vineet Reynolds 21.07.2011 - 08:37
2

Si tiene éxito y su equipo decide observar las advertencias, debe adoptar un enfoque gradual. Nadie puede y hará 10000 advertencias en una sola vez. Por lo tanto, puede seleccionar los más importantes (aquellos que son errores con alta probabilidad) y desactivar los menos importantes. Si son fijos, aumentar el nivel de advertencia de nuevo. Además, puede comenzar con FindBugs, que advierte sobre el código que casi siempre es un error.

    
respondido por el Heiko Schmitz 21.07.2011 - 09:00
1

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 hacer que el estilo del código sea consistente.

  1. defina 'Guardar acción' para cada proyecto Java, como el formato de código, las variables locales no utilizadas, la organización de las importaciones (creo que nadie tiene objeciones sobre este tipo de limpieza).
  2. defina las 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 genéricos), la asignación no tiene ningún efecto (por ejemplo, 'x = x') y así sucesivamente. Usted y su compañero de equipo pueden hacer un acuerdo para esos elementos, 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.

    
respondido por el Kane 21.07.2011 - 11:20
1

Tienes dos formas de deshacerte 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. Convenza a tu jefe de que esto es lo mejor que puedes hacer y hazlo obligatorio. Entonces necesitan arreglarlo.

Creo que 1 ya no es posible en tu caso. También es probable que esto lleve mucho tiempo debido a la cantidad de advertencias que se mostrarán en el rendimiento de la productividad, por lo que la gerencia deberá saberlo de todos modos.

Por lo tanto, mi sugerencia es: coméntenlo con el jefe, convencerlo de que es una bomba de relojería, y haga que sea una política oficial.

    
respondido por el Thorbjørn Ravn Andersen 21.07.2011 - 08:43
1

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

    
respondido por el WinW 21.07.2011 - 14:43
0

Necesitarás mucha paciencia para tratar de convencerlos, eliminar las advertencias al realizar la programación en pares ayudará a otros a adquirir el hábito. Sugiérales que lean el ítem 24 de Effective Java: elimine las advertencias sin marcar (para la colección genérica). Y probablemente ignore muchos casos en que las personas no siguen su consejo;)

    
respondido por el Mehul Lalan 21.07.2011 - 08:31
0

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

  1. Convenza a los jefes de administración / equipo de los beneficios de hacer esto (evitar que se implementen malas compilaciones, encontrar errores pronto, especialmente aquellos que afectan accidentalmente a otras partes del software, mantener las pruebas de regresión, realizar pruebas tempranas y con frecuencia, etc.) .)

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

  3. Configure correos electrónicos u otras notificaciones sobre el estado de cada compilación. Aquí es importante incluir quién verificó 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 genera visibilidad en todo el equipo tanto para los éxitos como para las fallas.

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

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

respondido por el Ben Taitelbaum 21.07.2011 - 11:02

Lea otras preguntas en las etiquetas