Cuándo desaprobar y cuándo eliminar en Java

Como parte de un esfuerzo de refactorización o simplemente de un desarrollo continuo, un método particular o tal vez una clase entera puede volverse obsoleto en algún sentido. Java admite la @Deprecatedanotación para indicar que probablemente haya una mejor manera de manejar la funcionalidad en cuestión. Me imagino que esto es particularmente útil en API públicas donde los efectos de eliminar partes de una API pueden no ser conocidos. Para una API no pública y un proyecto que utiliza sistemas de control de revisión (por lo que la eliminación puede deshacerse en algún sentido), ¿cuándo es apropiado desaprobar en lugar de eliminar los elementos obsoletos?

¿Es su API una API pública? Eso dicta si debes desaprobar o eliminar. Si la API es estrictamente para su beneficio (es decir, solo se usa dentro de su empresa), entonces es mejor simplemente eliminar el código ofensivo. Es mucho más limpio y causará menos dolores de cabeza de mantenimiento a largo plazo.

Sin embargo, si la API es pública, simplemente eliminar un método puede hacer que el código que solía funcionar con versiones anteriores de su biblioteca dejara de funcionar. Ahí es donde las cosas se complican. Las siguientes son algunas pautas:

• API interna: eliminar en lugar de desaprobar. Si algún cliente está usando una clase o método interno, es su culpa si la herramienta se rompe.
• API externa: desaprobar primero, eliminar después. La desaprobación es un indicador de que algo se eliminará más adelante. Más tarde depende de lo que creas que es razonable. Como mínimo, déle 2-3 versiones antes de eliminar el código obsoleto.

Probablemente sea una buena idea configurar un recordatorio cuando @desprecie una clase o método. Lo estás haciendo para promover su obsolescencia. Así que adivine cuánto tiempo tomará, como tiempo libre, como tarea, eliminar todas las referencias. Márquelo como @deprecated y ponga un recordatorio en su calendario. Cuando reciba el recordatorio, verifique. Si ya no se usa, elimínelo. Si quedan algunas referencias que se pueden actualizar rápidamente, hágalo y elimine el elemento. Si queda más trabajo significativo, adelanta un poco tu recordatorio.

Haga esto suficientes veces y desarrollará una idea de cuánto tiempo lleva deshacerse de una clase o método en sus proyectos.

En mi humilde opinión, si puede asegurarse de que nadie lo está usando y nunca lo hará, simplemente quítelo. (Esto puede ser complicado en presencia de reflexión o componentes externos como las macros Velocity; los IDE modernos como IntelliJ pueden encontrar referencias, por ejemplo, en JSP pero no a través de la reflexión o en Velocity).

Si hay una alternativa mejor, pero la anterior todavía se usa en muchos lugares, y actualmente no tiene tiempo para refactorizar todo el código del cliente, es adecuado @despreciar la clase / método obsoleto (con un comentario adecuado sobre La alternativa preferida).