Enfoque general para re-factorizar un sistema heredado grande, muy mal escrito [duplicado]

7

Pregunta realmente abierta aquí. No estoy buscando una respuesta ... sólo un consejo. Cualquier experiencia pasada que haya tenido la gente con sistemas de re-factorización heredados que podrían transmitir sería increíble. Aquí hay información sobre el software que debo modificar (¡te estremecerás!):

  • aplicación web
  • Base de datos controlada (MySQL)
  • PHP4 y PHP5
  • La mayoría del código es PHP4
  • Casi todo el código es procesal
  • El código que es PHP5 no es OO .. ejemplo: 10,000 líneas + archivo con una clase y una función
  • Variables globales utilizadas en todas partes
  • No se utilizó ningún control de origen para escribir el software (puede ver en los comentarios en el código)
  • Cantidades masivas de repetición de código
  • Sin separación de preocupaciones: la interfaz de usuario y la lógica se combinan en todas partes
  • La aplicación se basa en el orden de las tablas de la base de datos
  • Pocos comentarios de código
  • más de 250,000 líneas de código
  • Aplicación en uso intensivo

Básicamente, el software es nuestro producto principal y me han contratado para hacer un factor importante (entre otras cosas). Es una tarea masiva y no puedo simplemente sumergirme y arreglar todas las pequeñas cosas ... Necesito una estrategia general. Escribí algunos guiones para ordenar la sangría, eliminé el código comentado en todas partes y convertí el proyecto en un repositorio, pero ahora es el momento de hacer las cosas reales.

Tengo una vaga idea, pero no estoy seguro de cómo hacerlo. De alguna manera, podría dejar el código actual solo y escribir una capa de software sobre él que resista lejos de todo lo horrible. Sería bueno si la nueva capa fuera algún tipo de arquitectura MVC. Al mismo tiempo, entraría en el código actual, eliminaría las redundancias porque de lo contrario, la nueva capa estaría usando un código incorrecto de todos modos, por lo que el código podría ralentizarse aún más.

Como puedes ver ... ¡necesitas algunas pistas / consejos / sugerencias / consejos / experiencias!

Muchas gracias :).

    
pregunta ale 13.01.2012 - 13:11

1 respuesta

13

Ingeniería inversa dirigida por pruebas.

  1. Invierta la ingeniería en algunas epopeyas de usuario; no todas las historias, sino la serie de funcionalidades de "panorama general" que conforman el sistema.

  2. Priorice en función de la calidad, la capacidad de reemplazo, el valor, etc., etc. Esto es subjetivo, pero debe elegir una pieza para trabajar.

  3. Escriba las pruebas unitarias lo mejor que pueda para que pase el código heredado.

  4. Escribe un nuevo código solo para eso.

Ahora viene la parte difícil. Puentes.

Debe implementar la nueva parte y mantener el legado mientras avanza. Deberá "vincular" los datos de legado a nuevo (y de nuevo a legado).

También tendrás que escribir un montón de reglas de reescritura de Apache para redirigir las solicitudes a la nueva, de modo que las URL no parezcan cambiar demasiado o interrumpan demasiado. Algunos cambios son inevitables mientras reescribes. Algunos cambios son perjudiciales para los usuarios y requieren mod_rewrite, 304 redirecciones o ambas.

Una vez que haya implementado esa primera epopeya (un conjunto de historias) en producción, deberá repensar sus épicas y la descomposición de lo que queda en el legado que aún es valioso. Repriorizar

Escribe pruebas unitarias para la próxima epopeya. Reescribe el código. Crea y revisa los puentes. Despliega el siguiente fragmento.

Repetirá el bucle "particionar, priorizar, probar, refactorizar, desplegar" hasta que lo que quede como legado tenga tan poco valor que ya no necesite puentes. Entonces te retiras del viejo. Eliminar el código. Quema los puentes. No hay vuelta atrás.

    
respondido por el S.Lott 13.01.2012 - 13:23

Lea otras preguntas en las etiquetas