Mi proyecto está implementando lentamente anotaciones Java. La mitad de los desarrolladores, incluido yo mismo, descubrió que hacer algo complejo con las anotaciones parece aumentar nuestra carga de mantenimiento general. La otra mitad del equipo cree que son las rodillas de la abeja.¿Mantenibilidad de las anotaciones de Java?
¿Cuál es su experiencia en el mundo real con equipos de desarrolladores que pueden mantener el código anotado?
Creo que se divide en dos usos de anotaciones: las anotaciones para proporcionar una 'descripción' de una clase frente a las anotaciones para proporcionar una 'dependencia' de la clase.
Estoy de acuerdo con el uso de anotaciones en la clase de 'descripción' - eso es algo que pertenece a la clase y la anotación ayuda a hacer una versión abreviada de eso - las anotaciones JPA caen bajo esto.
Sin embargo, realmente no me gustan las anotaciones de "dependencia", si está poniendo la dependencia directamente en la clase, incluso si se determina en tiempo de ejecución a partir de una anotación en lugar de compilar en la clase, no es ¿esa inyección de ruptura de dependencia? (quizás en espíritu en lugar de en regla ...)
Puede ser una preferencia personal, pero I como el único archivo XML grande que contiene toda la información de dependencia de mi aplicación. Lo veo como 'configuración de la aplicación' en lugar de 'configuración de clase'. Prefiero buscar en una ubicación conocida que buscar en todas las clases de la aplicación.
Mi experiencia personal es que, en promedio, manejar anotaciones es mucho más fácil para la mayoría de los desarrolladores que lidiar con el infierno estándar de configuración XML de Java. Para cosas como las pruebas de JPA y Spring son protectores de vidas absolutos.
Lo bueno de las anotaciones es que hacen que la configuración en sus clases se auto-documente. Ahora, en lugar de tener que buscar a través de un enorme archivo XML para intentar averiguar cómo un framework está utilizando su clase, su clase le informa.
Por lo general, el problema con los cambios como este es que acostumbrarse a ellos simplemente lleva su tiempo. La mayoría de las personas, incluidos los desarrolladores, se resisten al cambio. Recuerdo cuando comencé a trabajar con Spring. Durante las primeras semanas me pregunté por qué alguien aguantaría los dolores de cabeza asociados. Luego, unas semanas más tarde, me pregunté cómo habría podido vivir sin ella.
I absolutamente amor anotaciones. Los uso de Hibernate/JPA, Seam, JAXB ... cualquier cosa que pueda. IMO no hay nada peor que tener que abrir un archivo XML solo para descubrir cómo se maneja una clase.
En mi opinión, las anotaciones permiten que una clase hable por sí misma. También las anotaciones son (afortunadamente) parte de la asistencia de contenido de IDEs, mientras que con la configuración de XML, por lo general, usted es el único.
Sin embargo, puede deberse a cómo las configuraciones XML y las anotaciones son realmente utilizadas por cualquier biblioteca en particular (ya que la mayoría ofrece ambas), y qué tipo de anotación se usa. Me imagino que las anotaciones que definen algo que es específico de la compilación (por ejemplo, rutas de archivos/url) pueden ser más fáciles que las configuraciones XML.
Depende altamente de la compatibilidad con IDE. Creo que las anotaciones deben mantenerse sincronizadas con el código a través de las comprobaciones en el IDE, pero falta algo de soporte para esto.
E.g.la versión anterior de IDEA advertiría si anula una función sin @Override, pero no eliminaría la etiqueta @Override si cambió la firma del método (o la firma de la superclase, para el caso) y rompió la relación.
Sin soporte, les resulta una forma engorrosa de agregar metadatos al código.
personalmente considero que el caso de uso específico que mencionó (autogenerar formularios web) es un buen caso de uso para las anotaciones. cualquier tipo de escenario "marco" donde se puede escribir código simplificado y dejar que el marco haga el levantamiento pesado (a menudo repetitivo) basado en algunas sugerencias (también conocidas como anotaciones) es, creo, el caso de uso ideal para las anotaciones.
tengo curiosidad por qué usted no como anotaciones en esta situación, y lo que usted considera que es la "carga de mantenimiento"? (y, no estoy tratando de insultar tu posición, solo entiéndelo).
No insultado en absoluto. Solíamos tener etiquetas personalizadas que hacen todo el trabajo propenso a errores repetitivos para nosotros en un JSP, por lo que era muy liviano para empezar. Los desarrolladores estaban familiarizados con esto. No es difícil de seguir, ya sea desde 10,000 pies o debajo de las sábanas. El JSP era * muy * fácil de seguir, por lo que si había un problema, la eliminación de errores era muy fácil. El nuevo sistema es difícil de agregar y/o cambiar. También tenemos un grupo de desarrolladores que tendrán problemas para aprender a usarlo. Cuando hay un problema con la pantalla, la depuración consiste en leer el código que la mayoría de los desarrolladores no conocen –
, así que me parece que su problema no está en las anotaciones, sino en el marco que está consumiendo las anotaciones. si es así, entonces el problema sería el mismo ya sea que esté usando anotaciones, archivos de configuración o lo que sea. – james
¿cómo está usando las anotaciones? No creo que haya una respuesta aquí, creo que realmente depende de cómo los está usando. – james
Excelente pregunta, ya que eso probablemente importa bastante en este caso. Los desarrolladores de pro-anotaciones han creado un marco para nuestra aplicación web. La aplicación usa Spring. Las anotaciones crean automáticamente formularios web basados en elementos en los objetos Command y evitan utilizar JSP por completo. No lo mencioné originalmente porque tenía curiosidad por la respuesta general; También tengo curiosidad por la respuesta específica. –
Compensando un comentario posterior:
Solíamos tener etiquetas personalizadas que hacen todo el trabajo propenso a errores repetitivos para nosotros en un JSP, por lo que era muy ligero para empezar. Los desarrolladores estaban familiarizados con esto. No es difícil de seguir, ya sea desde 10.000 pies o debajo de las sábanas, por lo que cuando hay un problema, la depuración es muy fácil.
El nuevo sistema es difícil de agregar y/o cambiar. También tenemos un grupo de desarrolladores que tendrán problemas para aprender a usarlo. Cuando hay un problema con la pantalla, la depuración consiste en leer un código que la mayoría de los desarrolladores no conocen. –