¿Por qué está ahí en primer lugar?
¿Ha ingresado código inestable en la línea principal? ¿Por qué?
El código inestable no debe ser registrado en trunk / main / master o como se llame. Se considera que se trata de un desarrollo de alto riesgo y, en lugar de ello, debería haber sido secuestrado en su propia sucursal en la que trabajó, en lugar de registrar en main.
Le recomendaría encarecidamente a usted (y al líder de su equipo) que lea Estrategias avanzadas de bifurcación de SCM . En particular, preste atención al rol de desarrollo y lo que dice sobre lo que se considera un desarrollo de alto riesgo:
En general, considere usar sucursales separadas para cada proyecto de alto riesgo. Los proyectos de alto riesgo se caracterizan por su gran tamaño, gran cantidad de personas, temas desconocidos, temas muy técnicos, plazos muy ajustados, fechas de entrega inciertas, requisitos incompletos o volátiles y equipos de proyectos distribuidos geográficamente. Del mismo modo, considere la posibilidad de designar una sola sucursal para el desarrollo de bajo riesgo en cada versión. Varias fuentes incluyendo [WING98] recomiendan usar la línea principal para este propósito. Considere los factores mencionados anteriormente para la línea principal antes de comprometerse con este curso de acción. El desarrollo de bajo riesgo puede tener una política diferente de la línea principal, incluso si tiene varios miembros de una familia de productos que se coordinan a través de la línea principal.
Permitir que las personas verifiquen el código inestable (o no utilizado) en la línea principal significa que confundirá los esfuerzos de desarrollo futuros al tratar de mantener este código. Cada rama y clon del representante desde ahora hasta el fin de los tiempos contendrá esto hasta que alguien diga "su código muerto" y lo elimine.
Hay algunos que dicen "bueno, si se olvida en una rama" y si bien eso puede ser cierto, haber olvidado el código muerto (e inestable) en la línea principal es muchas veces peor, ya que confunde todo el desarrollo futuro hasta que es eliminado, y luego se olvida más . Una rama con un nombre agradable de "/ fooProject / branches / WeisBigIdea" (o su equivalente) es visible y es más fácil trabajar con ella en el futuro, especialmente si funciona.
@Deprecated
Lo primero es la anotación @Deprecated
. Esto va más allá del javadoc y escupe advertencias del compilador. javac
proporciona un indicador -deprecation
que se describe como:
Muestra una descripción de cada uso o anulación de un miembro o clase en desuso. Sin -deprecation
, javac
muestra un resumen de los archivos de origen que usan o sobrescriben clases o miembros en desuso. -deprecation es taquigrafía para -Xlint:deprecation
.
Como se señaló, esto va más allá de las advertencias del compilador estándar.
En muchos IDE, los métodos y valores desaprobados se muestran tachados:
foo.bar();
Y produciría una salida como:
$ javac -Xlint:all Foo.java Bar.java
Bar.java:2: warning: [deprecation] Foo in unnamed package has been deprecated
interface Bar extends Foo { }
^
Dependiendo de la estructura de compilación, es posible que haya advertencias que interrumpan la compilación. Esto solo rompería la compilación si se usara una de tus clases (no si simplemente se compilara).
@CustomAnnotation
Hay muchos enfoques para esto. Por ejemplo, la javac ligera @ Anotación de advertencia que proporciona un procesador de anotaciones que dispara una advertencia en tiempo de compilación cuando algo con esa anotación se utiliza ( un tutorial de netbeans sobre procesadores de anotaciones personalizados para que pueda tener una idea de lo que está pasando detrás de las escenas).
Oracle incluso describe un ejemplo de uso de anotaciones personalizadas para una anotación @Unfinished
en Making la mayoría de los metadatos de Java, Parte 2: Anotaciones personalizadas .
Con el AnnotationProcessor , puede ejecutar un código arbitrario en tiempo de compilación. Depende de usted decidir qué quiere que haga. Advertir, romper la construcción cuando se utiliza algo. Existen numerosos tutoriales en la web sobre cómo escribir este tipo de código. Si desea generar un error cuando se compila (esto será molesto y hará que se elimine) o si se usa (algo más complejo de escribir).
Tenga en cuenta que todo esto implica cambiar las compilaciones para utilizar realmente el procesador de anotaciones.