¿Cómo manejar las funciones de desactivación en la biblioteca?

Question

Estoy trabajando en una biblioteca Java y me gustaría eliminar algunas funciones de ella. Mis razones para esto son la API pública y la limpieza del diseño. Algunos objetos tienen setters, pero deben ser inmutables, algunas funcionalidades se han implementado mejor/clean en diferentes métodos, etc.

He marcado estos métodos como 'obsoletos' y me gustaría eliminarlos eventualmente. Por el momento estoy pensando en eliminar estos después de algunos sprints (ciclos de desarrollo de dos semanas).

¿Hay alguna 'mejores prácticas' para eliminar el código público redundante?

/JaanusSiim

Answer 1

Establezca una fecha y publíquela en la etiqueta @deprecated. La cantidad de tiempo otorgada a la eliminación depende de la cantidad de usuarios que tenga su código, qué tan bien conectado esté con ellos y el motivo del cambio.

Si tiene miles de usuarios y apenas se habla con ellos, el marco de tiempo probablemente debería ser en las próximas décadas van :-)

Si los usuarios son sus 10 compañeros de trabajo y que los ven todos los días, el plazo puede estar fácilmente en el rango de semanas.

/** 
* @deprecated 
* This method will be removed after Halloween! 
* @see #newLocationForFunctionality 
*/ 

Answer 2

Uso @deprecated etiqueta. Lea el documento Deprecation of APIs para obtener más información.

Después de todos los que usan el código que dice que han limpiado de su lado, empezar a eliminar el código obsoleto y esperar a ver si alguien se queja - a continuación, diles que fijar su propio código ...

Answer 3

Depende con qué frecuencia se reconstruye el código Por ejemplo, si hay 4 aplicaciones que usan la biblioteca y se reconstruyen diariamente, un mes es el tiempo suficiente para arreglar las llamadas obsoletas.

Además, si utiliza la etiqueta en desuso, proporcione algún comentario sobre qué código reemplaza la llamada obsoleta.

Answer 4

Considérelo de esta manera, el cliente A descarga la última versión de su archivo de biblioteca o marco de trabajo. Acierta compilación en esta máquina y de repente ve miles de errores porque el archivo miembro o la función ya no existe. A partir de este punto, le ha dado al cliente un motivo por el que no debe actualizar a su nueva versión y quedarse con la versión anterior.

Raymond Chen respuestas sobre este el mejor con su blog acerca de la API de Win32,

Sin embargo, nuestra experiencia en nuestra casa de software ha sido, una vez que la API se ha escrito que tenemos que llevar a la API para el final del producto ciclo vital. Para ayudar a los usuarios a obtener nuevas versiones, brindamos compatibilidad con versiones anteriores con los comandos anteriores en el nuevo marco.

Answer 5

Dado que se trata de una biblioteca, considere archivar una versión con las funciones obsoletas. Haga que esta versión esté disponible tanto en el código fuente como en el formulario compilado, como una solución de respaldo para aquellos que no han modernizado su código a su nueva API. (La forma binaria es necesaria, porque incluso usted puede tener problemas para compilar la versión anterior en unos pocos años). Deje en claro que esta versión no será compatible ni mejorada. Etiquete esta versión con un símbolo simbólico en su sistema de control de versiones. Entonces sigue adelante.

Answer 6

lástima que no está utilizando .Net :(

El construido en Obsolete atributo genera advertencias del compilador.

Answer 7

Sin duda, depende de a qué escala se use su API y de lo que prometió por adelantado a sus clientes.

Según lo descrito por Vinko Vrsalovic, debe ingresar una fecha en la que tengan que esperar el abandono de la función.

En producción, si es "solo" cuestión de obtener un código más limpio, tiendo a dejar las cosas en su lugar incluso después de la fecha de desaprobación, siempre y cuando no rompa nada.

Por otro lado en el desarrollo lo hago de inmediato, con el fin de resolver las cosas rápidamente.

Answer 8

Le pueden interesar ejemplos de cómo funciona la degradación en algunos otros proyectos. Por ejemplo, aquí sigue lo que es policy in the Django project for function deprecation:

Una versión menor puede anular ciertas características de versiones anteriores. Si una característica en la versión A.B está en desuso, continuará funcionando en la versión A.B + 1. En la versión A.B + 2, el uso de la función generará una Advertencia de Detención Pendiente, pero continuará funcionando. La versión A.B + 3 eliminará la característica por completo.