systems software sistemas sistema significa segunda que migración metodología heredados heredado etapa ejemplos definicion caracteristicas apoyo c# .net asp.net javascript

c# - software - ¿Qué hace con el código no utilizado en sus aplicaciones heredadas?



sistemas heredados pdf (18)

  1. Marcalo obsoleto. http://msdn.microsoft.com/en-us/library/aa664623%28VS.71%29.aspx
  2. Próximo ciclo, comente el código y haga los comentarios apropiados. Establezca una región alrededor del bloque de código para que se colapse de forma agradable y no consuma mucho espacio visual.
  3. Siguiente ciclo, borre el código.

De esta forma, no sorprenderá demasiado a sus compañeros de equipo si necesita desaprobar algún código al que está asignado pero al que necesitan llamar. ¡Pero te permite hacer esos cambios necesarios!

En aplicaciones de gran legado es bastante común ver cambios en las reglas de negocios que conducen a código no utilizado. ¿Es la eliminación de la mejor manera? o ¿Hay algún estándar para marcar el código no utilizado? SCM ayuda a recuperar el código antiguo si es necesario. También esto es específico para las bases de código .NET.


  1. Verifique el proyecto anterior en Source Control.
  2. Eliminar código no utilizado.
  3. ¡¡Lucro!!

¿Qué sucede si el código para alguna funcionalidad que no es necesaria, pero que podría ser necesaria en el futuro, se encuentra dispersa en todo el programa? El uso de #ifdef para controlar dicho código (mantener en un archivo una lista maestra de todas las etiquetas #define utilizadas para ese propósito) puede permitir que la función se habilite o deshabilite a voluntad; Intentar reincorporar todos los pequeños fragmentos de código de un sistema de control de versiones parecería más difícil.


Borro el código, pero primero me aseguro de que no cause problemas más adelante. Si lo necesito más tarde, lo obtengo del control de código fuente y uso una característica interesante: la comparación de códigos y puedo ver qué es lo que ha cambiado. No le comento el código no utilizado, porque si otro desarrollador está mirando el código, es difícil entender por qué no se usa (especialmente si el desarrollador no pone comentarios por el motivo). Así que borrar el código lo mantendrá simple y claro.


Creo que eliminar es una buena manera de mantener el código limpio.

Si no borras, por ejemplo: comentar o crear entidades obsoletas para almacenarlas, he visto un desastre como este.

Y es por eso que tienes repositorios, sucursales, tags, etc.

Me parece mejor borrarlo. Si el código ya está en el repositorio.


Creo que esto fue respondido en la conferencia de Refuctoring - http://www.waterfall2006.com cuando se habla del "Módulo de Día Lluvioso" - debe escribir un código de repuesto en caso de que alguien lo necesite más tarde ...

class SpareCode { private int spareInteger; private String luckyString; private bool youNeverKnow ; public void spareLogic() { spareInteger = 1; if ( youNeverKnow ) { spareInteger++; } System.out.println( luckyString); }


Creo que la mejor manera es hacer el control de versión de su proyecto, por ejemplo, SVN, CVS. Y luego eliminar el código no utilizado. Para reducir el tamaño del archivo fuente que se está compilando y evitar ensuciarse con el código no utilizado.


Definitivamente borra el código no utilizado. En mi experiencia, el mayor problema con los códigos de base heredados es entender qué está pasando con el código: menos código significa menos que entender, facilitando su trabajo.

Como dice, siempre puede recuperarlo si está usando el control de código fuente (está usando el control de código fuente, ¿verdad?) Y, a menos que esté haciendo algo un poco extraño (como compilar dinámicamente el código o cargar el código a través de la reflexión), probablemente vaya para descubrir rápidamente si eliminó el código incorrecto ya que su construcción fallará.


La mejor manera de marcar el código heredado no utilizado es eliminarlo. No sirve más que para confundir a los nuevos desarrolladores con el equipo.

En mi antiguo equipo, de hecho, convertimos esto en una competencia que llamamos la competencia Grim Repear. Quién podría encontrar y eliminar la mayor cantidad de código no utilizado / muerto en la base de código. Se otorgaron puntos negativos por eliminar el código muerto y los puntos positivos por agregar código muerto. El puntaje más bajo gana.


Lo comento de la misma manera que comento mi System.out.println''s antes de comenzar a funcionar.


Personalmente, elimino el código que no uso y confío en el control de código fuente para realizar un seguimiento del mismo. Aunque no uso VSS y no lo haría.

Sin embargo, hay una excepción a esta regla ... A veces, si borro el código en un lugar donde es demasiado tentador para que otra persona piense que tiene que estar allí, lo dejo con una nota rápida para que no lo hagan. trabajo deshecho.


Por lo general me marca eso obsoleto:

/// <summary> /// Purpose of this method /// </summary> /// <param name="args">Argument 1</param> [Obsolete("This method is obsolete, use NewMethod instead")] public void SampleMethod(string args) { //code } /// <summary> /// Purpose of this method /// </summary> /// <param name="args">Argument 1</param> public void NewMethod(string args) { //code }

Ahora el compilador proporcionará una advertencia siempre que se utilice el método marcado como Obsoleto.


Prefiero borrarlo. El control de fuente mantendrá el historial de lo que había allí (y quién lo eliminó). Odio buscar código y ver resultados en código comentado, especialmente cuando el código se comenta usando /*...*/ que no se puede ver en el resultado de búsqueda de archivos en lugar de // que al menos me da la oportunidad de ver Que el resultado sea comentado.


Si tengo un código que ya no utilizo, lo vendo en Craigslist.


Un buen lugar para aplicar una lesson del libro Pragmatic Programmer.

Copia de seguridad y luego borre todo el código no utilizado. Confía en mí, salvará a los desarrolladores de futuros dolores de cabeza. Si duda en pensar que podría necesitar alguna funcionalidad futura basada en código comentado, no vale la pena intentar comprender el código o la lógica no utilizados. Es mejor comenzar con un estado de ánimo limpio sin la necesidad de descifrar, obviamente, el código a medias, sin probar de todos modos.


Siempre borro el código no utilizado. Este es uno de los beneficios del control de la fuente.


Elimine el código no utilizado en su aplicación heredada.

Si tiene el control de código fuente, eliminar el código no utilizado no dañará nada porque su historial se guarda en cualquier software de control de versión que esté utilizando. El código limpio ayuda al siguiente desarrollador cuando él o ella tiene que entrar y hacer cambios. El código antiguo solo confunde el problema cuando se deben hacer cambios.


Tome un consejo de Michael Jackson:

Solo bórralo ... bórralo ... bórralo ... bórralo ...

Nadie quiere ser derrotado

Demostrando lo funky y fuerte que es tu lucha.

No importa quién está equivocado o correcto

Solo bórralo ... bórralo ... solo bórralo ... bórralo ...