UTNianos

Hola como va?

Actualmente estoy laburando en un sistema Python.
Me acabo de enterar, después de muchos años de programar en diferentes lenguajes, que existe un tag de "deprecated" que se utiliza en muchos lenguajes en general.

En Python simplemente es un decorador llamado "@deprecated".
Aparentemente cuando se actualiza un sistema y un método se deja de usar y, en su lugar, se desarrolla uno nuevo, se opta por dejar el método viejo para mantener "la compatibilidad hacia atrás" (o sea, que no sea necesario refactorizar todo el sistema por ese cambio, o que ciertas dependencias puedan seguir usando la firma vieja) con un tag de "deprecated", el cual le advertiría al usuario con un Warning que ese método está quedando obsoleto y que hay otro mejor incorporado.

¿Saben cuán común es esto y si existe una linea de fundamentos a seguir para plantear si un método se lo debe "deprecar" o no?

Creí que era una práctica rara o poco común, pero después de hablarlo con algunos compañeros parece que estaba algo equivocado.

Saludos!

Es práctica común para no romper compatibilidad y avisarle al usuario "che, no uses esto porque en la proxima version de la API lo vuelo".
Asumiendo que en la siguiente versión realmente elimines la función deprecada, claro.

Las APIs cambian, porque los sistemas cambian.

Para manejar los cambios de versiones de manera más feliz, inventaron Semantic Versioning.

Es un estándar que pretende ponernos de acuerdo para comunicar qué esperar al cambiar de versión de un software.

La idea es que los cambios de API que rompen compatibilidad hacia atrás (como los que describís) ocurren únicamente al cambiar de versión major (es decir, al pasar de 2.x a 3.0, ponele). En los minors (de 2.3.x a 2.4.0) metés APIs _nuevas_, sin romper las que estaban. Y el los patchs (de 2.3.2 a 2.3.3) únicamente arreglas bugs.

Si estás en, digamos, 2.1.4 y querés cambiar la firma de un método público pero "de a poco", lo que hacés es crear un nuevo método con la nueva firma, deprecar el viejo, y sacar 2.2.0: el código que funcionaba contra 2.1.4 sigue funcionando, pero el código que use las novedades de 2.2.0 (el método que acabás de crear) no funciona con versiones previas.

Después de un tiempo de tener el coso ese deprecado, en que fuiste avisando a tus usuari@s que dejen de usar el método viejo y pasen al nuevo, podés sentirte libre de hacer mierda el método viejo. Como ese cambio hace que el código viejo deje de andar, ahí tenés un nuevo major: 3.0.0.


Cuánto tiempo/versiones dejar con el código deprecado es una decisión tuya. Va a depender, principalmente, de cuán difícil sea migrar de un método a otro para tus usuari@s, y de cuánto te cueste a vos mantener ambas versiones andando.