Tengo la tarea de mantener un sistema modestamente grande (~ 60k LOC de Perl no Moose OO). Estoy empezando a cuestionar la sabiduría de refactorizarlo en lugar de reescribirlo. Sé que esta cuestión se ha discutido extensamente, pero la situación es inusualmente compleja y tiene varios elementos que apuntan fuertemente en direcciones opuestas, de ahí mi pregunta. Perdón por la verbosidad de la pregunta; es lo más conciso que pude lograr al transmitir toda la imagen.¿Debo abandonar la refacturación y planificar una nueva redacción?
Según el sistema, sus abstracciones son bastante insuficientes para encapsular algo limpiamente, como lo demuestra la dependencia frecuente de la acción a distancia, el uso abundante de bloques if/else con conocimiento íntimo de objetos de un tipo no relacionado con el módulo en cuestión y un gráfico de dependencia que se parece a una red social. Esto, sentí, era malo, pero podría ser refactorizado.
La cobertura de la prueba es irregular. Esto es, por supuesto, reparable y debe ser reparado antes del refactor. Por supuesto, en un sistema como ese, las pruebas necesitan cantidades absurdas de andamios, lo que hace que la mejora de la cobertura de la prueba sea más ardua, pero aún así, es casi imposible.
Y así que había planeado pasar mucho tiempo lentamente ordenando el orden en el caos. Difícil, pero factible, pensé, y el sistema funciona bastante bien para fines comerciales, a pesar de todos sus problemas, por lo que debe estar haciendo algo bien. Y "todos saben" reescribir algo como esto es una receta para el desastre.
Pero recientemente, descubrí que algunas de las partes más vitales y mal escritas del sistema tienen errores de diseño profundamente asentados y serios que llegan hasta el esquema de datos. Toda la metodología tiene problemas importantes (esto es consenso entre los que han trabajado en ella, no solo yo) y las soluciones para eso probablemente constituyen la mitad del código en esa parte, aunque está tan mal escrito que no hay esperanzas de diferenciarlos de los demás. lógica de negocios. El código es demasiado intrincado para mí (solo he estado trabajando en él durante unos meses) o el mantenedor principal anterior (de varios años) para comprenderlo por completo. También tiene menos del 10% de cobertura de prueba.
Nadie confía en que puedan describir completa y correctamente lo que hace esa parte, mucho menos cómo. Obtener una buena cobertura de prueba para esta parte es casi imposible cuando el código es indescifrable y los requisitos que cumple no se comprenden bien. Refactorizar sin cobertura de prueba no es correcto, ni es remotamente práctico en un sistema de este tamaño, complejidad, con problemas tan generalizados (y tipeado dinámicamente hace imposible el descubrimiento automatizado de los impactos de un cambio).
Dejar esta y las esquinas oscuras intactas no es una opción debido a los requisitos comerciales constantemente cambiantes.
La única salida práctica que puedo ver comienza con la redefinición de los requisitos del sistema a nivel comercial y el compromiso de cumplir con esa especificación y arriesgar cualquier rotura que nadie anticipó. Sé que es una mala estrategia, pero no veo alternativa. Si se elige como el camino a seguir, parece que gran parte del beneficio de la refactorización se va por la ventana, lo que me deja cuestionando seriamente la virtud de incluso intentar refactorizar esto.
Esto me lleva a la pregunta específica: ¿La refactorización es una mala estrategia en este caso? Las respuestas respaldadas con experiencias reales son muy preferidas ya que creo que los aspectos teóricos están bien establecidos aquí y en otros lugares.
La gran bandera roja en esto es ... ¡en realidad no sabes lo que hace el código! Seguramente tienes que llegar al punto donde has entendido y documentado el código antes de que puedas realmente considerar seguir adelante. – AmbroseChapel
+1: Creo que esta es una excelente pregunta. No estoy seguro de por qué algunos piensan que es demasiado localizada, ya que esta publicación podría proporcionar una excelente guía para otros en el mismo barco. – Zaid