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)
javac
.-Wall -Wextra -Werror
(es decir, activar la mayoría de las advertencias disponibles, tratarlas a todas como errores). Eclipse C ++ es casi inutilizable: /Respuestas:
Puedes hacer dos cosas.
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.
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
@Override
no es una "obsesión". Esa es una buena cosa. ¿Alguna vez escribió mal el nombre de un método?fuente
if (error = 0)
lugar deif (error == 0)
. Además, muchas advertencias también hacen que sea mucho más fácil encontrar errores de compilación sin tener que atravesar una gran cantidad de advertencias.Lectura relevante aquí . C ++, pero sigue siendo relevante. Me gusta especialmente este ejemplo (el comentario de código es mío):
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:
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 :)
fuente
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
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.
fuente
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.
fuente
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.
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.
fuente
Tiene dos formas de deshacerse de todas las advertencias (y estoy de acuerdo en que puede ocultar un error sutil):
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.
fuente
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!
fuente
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;)
fuente
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.
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.)
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).
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.
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.
(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ó.
fuente