net - help attribute c#
Uso del atributo obsoleto (5)
Recientemente me dijeron que era una mala práctica haber marcado varios métodos en nuestro código con el atributo [Obsolete] . Estos métodos eran internos a nuestro código base, en lugar de estar en una API. Los métodos manejaban una función de cifrado anterior.
Sentí que era una forma rápida y segura de denunciar al resto del equipo que estos métodos no deberían usarse, y proporcioné un mensaje para sugerir alternativas.
Otros consideraron que debería haber eliminado los métodos por completo, reescribiendo o refactorizando el código existente según sea necesario. Además, se pensó que era demasiado fácil pasar por alto las advertencias del compilador.
¿Existe una "mejor práctica" para marcar el código como obsoleto cuando no está siendo utilizado por terceros? ¿O es esto en gran parte subjetivo?
Depende. Sí, PODRÍA refactorizar el código. ¿PODRÍAS?
El problema es que usted puede refactorAR DENTRO DE UN PROGRAMA. Es mucho más difícil si la API está disponible para el público y simplemente NO PUEDE refactorizar el código usando su API. Esto es lo que está hecho para obsoleto.
Si la API es interna a su código, entonces la refactorización es el camino a seguir. Limpie el código, no deje un lío.
Pero si la API pública cambia, debería, si es posible, hacerse lentamente.
El resto sigue siendo subjetivo. No me gusta "Obsoleto" para las API internas.
Lo he usado antes como una especie de estado temporal de cosas cuando tenemos un código antiguo que necesita ser refactorizado eventualmente pero no urgentemente . En la mayoría de los casos, este es el caso cuando se ha escrito algún código nuevo que hace el trabajo mejor que el anterior, pero nadie en el equipo tiene tiempo para volver y reemplazar un montón de código antiguo en este momento. Obviamente, esto implica una situación en la que no es posible un reemplazo directo simple (a veces, el nuevo código hace casi todo lo que hizo el código anterior, pero aún hay una pequeña funcionalidad que aún no se ha implementado).
Luego, tener todas esas advertencias del compilador por ahí es un recordatorio constante para que alguien regrese y termine la refactorización cuando tenga un poco de tiempo libre.
Si esto es realmente algo bueno o malo es bastante subjetivo. Es una herramienta, como cualquier otra.
No es un caso sencillo. Si elimina los métodos de una aplicación que funciona y refactoriza el código, creará la posibilidad de introducir nuevos errores y romper una aplicación que funcione. Si esa aplicación tiene una misión crítica, el impacto podría ser enorme y le costaría mucho dinero a la empresa, cambios como este deberían planificarse y probarse cuidadosamente. En ese caso, los métodos de marcado como obsoletos podrían valer la pena, deberían ayudar a evitar que las personas los utilicen en un desarrollo posterior, facilitando así la refactorización final. Sin embargo, si la aplicación no es crítica o el potencial de introducción de errores es bajo, entonces puede ser mejor refactorizar, si tiene tiempo. En última instancia, agregar el atributo [Obsolete] es un poco como un todo y su uso depende de muchos factores.
Paso 1. Marque el miembro o la clase como [Obsoleto]
Paso 2. Actualice todos los usos internos del miembro o la clase para usar el nuevo enfoque que reemplaza el enfoque obsoleto, o marque ese miembro o clase como [Obsoleto]
Paso 3. Si has marcado cosas nuevas como [Obsoleto] en el Paso 2, repite este paso según sea necesario.
Paso 4. Eliminar todos los miembros y clases obsoletos que no sean públicos ni utilizados por un miembro o clase públicos obsoletos.
Paso 5. Actualice la documentación para proporcionar una descripción más clara del enfoque recomendado para reemplazar cualquier clase o miembro público obsoleto.
Al final de esto, no tendrá ningún código obsoleto que solo sea utilizado por el código interno. No hay nada que decir que tienes que hacer todo esto de una sola vez; En cada etapa has progresado. El tiempo entre el inicio del paso 1 y el final del paso 5 puede ser de 5 segundos o 5 años, dependiendo de muchos factores (la mayoría de ellos relacionados con la complejidad).
Por cierto, si a alguien le resulta fácil ignorar las advertencias del compilador, el problema no es con [Obsoleto]. Sin embargo, una razón para no dejar esas llamadas en el código por mucho tiempo (es decir, haber hecho hasta el paso 2 lo antes posible) es asegurarse de que la gente no se acostumbre a las advertencias del compilador, ya que son parte de la Respuesta habitual a la compilación del código.
Pienso que es subjetivo. Si es interno y es un proceso bastante rápido, realizaría el cambio.
Sin embargo, también tuve la situación de que la refactorización correspondiente tomó mucho más tiempo (muchas llamadas a lo largo del código base), en cuyo caso usé el atributo [Obsolete] . En este caso, el nuevo desarrollo utilizaría las nuevas funciones y quien haya realizado refactorizaciones durante el tiempo hasta que todas las llamadas hubieran desaparecido, lo que significaba que el método podría eliminarse.