¿Cómo mantendrías las aplicaciones heredadas [cerrado]?

Question

¿Cómo mantendrías las aplicaciones heredadas que:

1. Las pruebas unitarias no tienen métodos grandes

2. con una gran cantidad de lógica duplicada

3. no hay separación de preocupación
4. tienen muchos cortes rápidos y codificados cuerdas
5. ha caducado y está mal documentación
6. Los requisitos no están debidamente documentados ! Esto en realidad ha resultado en disputas entre los evaluadores, los desarrolladores y los clientes en el pasado. Por supuesto, hay algunos requisitos no funcionales, que no deberían ser lentos, no deben fallar y otras lógicas de negocios que conocen los usuarios de la aplicación. Pero más allá del escenario de sentido más común y el flujo de trabajo empresarial de sentido más común, hay poca orientación sobre lo que se debe (o no) hacer.

???

Answer 1

Necesita el libro Cómo trabajar con eficacia con el código heredado por Michael C. Feathers .

Answer 2

Escribe pruebas tan pronto como puedas. Preferiblemente en contra de los requisitos (si existen). Comenzar con las pruebas funcionales. Refactor en pequeños trozos. Cada vez que toque el código, déjelo más limpio y mejor que cuando comenzó.

Answer 3

Dos cosas.

1. Escribe pruebas unitarias cuando tengas la oportunidad.
2. Una vez que tenga suficientes pruebas unitarias para estar seguro, comience a refactorizar.

La velocidad a la que se logra esto puede ser lenta ... Por lo general, se supone que debes " mantenerlo " no arreglarlo

Durante el " aprender a mantenerlo " En la fase, sin embargo, puedes escribir muchas pruebas unitarias.

Luego, a medida que se detectan errores y se solicitan mejoras, puede agregar más pruebas.

Es ágil, aplicado al legado.

Answer 4

He visto, trabajado y estoy trabajando en un código base que cumple todas las condiciones que se mencionan en la pregunta :-)

El enfoque seguido para mantener este código base es NO RETRAR NADA . FWIW, el código funciona y los usuarios finales están contentos. Nadie va a escuchar a los desarrolladores que gritan que hay duplicación de código, cadenas codificadas, etc. Simplemente robamos un poco de tiempo para arreglar lo que sea posible y cuidamos al máximo para no introducir nuevos errores ...

Answer 5

Creo que crearía un pequeño conjunto de información actualizada: qué acción llama a qué funciones, etc.

A partir de ahí, me gustaría ver refactorización. La lógica duplicada parece ser algo que podría ser refaccionado, pero recuerda que

• Eso puede ser una tarea enorme cuando te das cuenta en cuántos lugares se llama la lógica y
• Dos funciones que parecen similares pueden tener una pequeña diferencia, es decir, una - en lugar de una +

Creo que la mayor necesidad de resistir es " ¡Solo reconstruye toda la maldita cosa! " y obtenga primero una descripción general del sistema, para desmitificar a la bestia.

Answer 6

sudo rm -rf /

Pero más seriamente, creo que tiene que ser evaluado. Si el código es continuamente una fuente de solicitudes de cambio y los cambios son difíciles, no tardará mucho en considerar si vale la pena intentar refactorizar / rediseñar el sistema para que sea más moderno. Por supuesto, esto no siempre es práctico, por lo que a menudo terminas con unas pocas personas en el equipo que son responsables de mantener las partes heredadas. En la medida de lo posible, todos los miembros del equipo deben poder mantener todas las partes del sistema ...

Una cosa más que creo que es importante es hacer un seguimiento de la cantidad de tiempo y esfuerzo que un equipo dedica a trabajar en un sistema heredado al realizar solicitudes de mantenimiento / características. Estas métricas pueden ser convincentes al evaluar la planificación de un nuevo esfuerzo para reemplazar los sistemas / componentes heredados.

Answer 7

Básicamente estoy de acuerdo con todo lo que dijo Paul C. No soy un sacerdote de TDD, pero cada vez que estás tocando una base de código heredada, especialmente una con la que no estás familiarizado, necesitas tener una forma sólida de volver a realizar la prueba y asegurarte de haber seguido a Hipócrates: primero , no hagas daño. Las pruebas, las pruebas de buena unidad y de regresión en particular, son casi la única forma de hacer esa jugada.

Recomiendo encarecidamente recoger una copia de Invertir: Secretos de ingeniería inversa Software si es un código base con el que no está familiarizado. Aunque este libro llega a grandes profundidades que están fuera de sus necesidades actuales (y las mías, en realidad), me enseñó mucho sobre cómo trabajar de forma segura y sana con el código de otra persona.