2010-08-18 37 views
19

Recientemente me dijeron que era una mala práctica marcar un número de métodos en nuestro código con el atributo [Obsolete]. Estos métodos son internos a nuestra base de código, en lugar de estar en una API. Los métodos manejaban una función de cifrado anterior.Uso del atributo obsoleto

Sentí que era una forma rápida y segura de indicar al resto del equipo que estos métodos no deberían utilizarse, y proporcioné un mensaje para sugerir alternativas.

Otros consideraron que debería haber eliminado completamente los métodos, reescribiendo o refactorizando el código existente según sea necesario. Además, se pensó 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?

+2

Parece una razón para forzar que las advertencias sean errores –

+0

@Matt - True; ahora hemos realizado este cambio para evitar que se use [Obsoleto] en el futuro, entre otras cosas –

+2

No hay nada de malo en usar '[Obsoleto]' en este caso. El hecho de que haya creado un widget mejor no significa que tenga tiempo de atravesar y destruir todos los lugares donde se usa el widget malo. Al menos, al marcarlo como obsoleto, indicó que las personas no deberían usarlo en el futuro y eliminarlo cuando sea posible. –

Respuesta

26

Paso 1. Marque el miembro o clase como [obsoleto]

Paso 2. Actualizar todos los usos internos del miembro o de la clase a utilizar el nuevo enfoque que reemplaza el enfoque obsoleto, o marcar ese miembro o clase en sí mismo como [Obsoleto]

Paso 3. Si marcó cosas nuevas como [Obsoleto] en el Paso 2, repita este paso según sea necesario.

Paso 4. Eliminar todos los miembros obsoletos y las clases que no son públicas ni utilizadas por un miembro o clase público obsoleto.

Paso 5. Actualice la documentación para dar una descripción más clara del enfoque recomendado para reemplazar cualquier miembro o clase pública obsoleta.

Al final de esto, no tendrá un código obsoleto que solo se use por código interno. No hay nada que decir que tienes que hacer todo esto de una vez; en cada etapa has progresado. El tiempo entre el inicio del paso 1 y el final del paso 5 podría 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 tales llamadas en el código por mucho tiempo (es decir, haberlo hecho tan pronto como sea posible) es asegurarse de que las personas no terminen acostumbrándose a las advertencias del compilador, ya que son parte del respuesta habitual a la compilación del código.

+3

+1 por respuesta excelente. Cubre muy bien la ejecución técnica y el aspecto psicológico (desde la perspectiva del desarrollador) de este problema. – Shiva

+0

nuevo C# rechaza la serialización, así que tenga cuidado. – deadManN

7

Creo que es subjetivo. Si es interno y es un proceso bastante rápido, entonces realizaría el cambio.

Sin embargo, también he tenido la situación en la que la refactorización correspondiente tomó mucho más tiempo (muchas llamadas en todo el código base), en cuyo caso usé el atributo [Obsolete]. En este caso, el nuevo desarrollo usaría las nuevas funciones y quien tuviera tiempo realizó refactorizaciones hasta que todas las llamadas se hubieran ido, lo que significaba que el método podría eliminarse.

+0

si introduce el atributo [Obsoleto], tiene que corregir todas las advertencias de compilación resultantes usted mismo. De lo contrario, solo ensucia su propio código fuente. –

+3

¿De verdad leíste lo que escribí? Es una medida temporal para una refactorización más grande. ¿Y luego bajaste? Ts ... – flq

+0

No me gustó "y quienquiera que haya tenido tiempo realizó refactorizaciones hasta que todas las llamadas se fueron". Lo veo a veces en proyectos grandes. Algunas personas ponen atributos obsoletos y arreglan allí el área principal de preocupación. Luego espere a que alguien más "que tiene tiempo" arregle otros usos. –

5

Depende. Sí, PODRÍA refactorizar el código. ¿PODRÍAS?

El problema es - refactor youCAN DENTRO DE UN PROGRAMA. Es mucho más difícil si la API está en el público y usted NO PUEDE refactorizar el código usando su API. Esto es para lo que está hecho Obsoleto.

si la API es interna para su código, entonces la refactorización es el camino a seguir. Cierra el código, no dejes 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.

+0

+1 Sensible. Existen herramientas (ReSharper) que pueden refactorizar sistemáticamente el código interno que depende de una API, y si tiene cobertura de prueba unitaria, dichas refactorizaciones deberían ser seguras. (Si no tiene cobertura de prueba unitaria, ¿debería cambiar realmente este código en primer lugar?) –

+0

Gracias por sus pensamientos, alguien más que piensa que este atributo es un "desastre" cuando se usa internamente. (Tenga en cuenta que el código en cuestión no se accedió a través de una API, estaba en una biblioteca interna.) –

+0

Definitivamente refactorizaría. El punto es - elimina el código. Código doble = costoso;) – TomTom

2

No es una caja sencilla. Si elimina los métodos de una aplicación en funcionamiento y refactoriza el código, crea la posibilidad de que introduzca nuevos errores y rompa una aplicación en funcionamiento. Si esa aplicación es crítica, el impacto podría ser enorme y le costaría a la compañía mucho dinero, cambios como ese tendrían que ser planeados y probados cuidadosamente. En ese caso, los métodos de marcado como obsoletos podrían valer la pena, debería ayudar a evitar que las personas los usen en un desarrollo posterior, facilitando así la eventual refactorización. Sin embargo, si la aplicación no es crucial o si la posibilidad de que se introduzcan errores es baja, 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.

3

lo he usado antes como una especie de situación temporal cuando tenemos código antiguo que necesita ser reprogramado finalmente pero no con urgencia. En la mayoría de los casos, este es el caso cuando se ha escrito un nuevo código que hace el trabajo mejor de lo que venía antes, pero nadie en el equipo tiene tiempo para volver atrás y reemplazar mucho código antiguo en este momento. Obviamente, esto implica una situación en la que un simple reemplazo directo no es posible de inmediato (a veces el nuevo código hace casi todo lo que hacía el código anterior, pero hay una pequeña funcionalidad que todavía no se ha implementado).

Tener todas esas advertencias de compilador sentadas 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.

+0

¡Bastante!El atributo parecía servir como un recordatorio de que este código debería ser considerado para su eliminación en el futuro sin tener que tomar esa decisión al acercarse a un lanzamiento. –