Casi cualquier cosa puede analizarse en términos de costos y beneficios, y creo que esto se aplica aquí.
Los beneficios obvios de la primera opción son que minimiza el trabajo a corto plazo y minimiza las posibilidades de romper algo al reescribir el código de trabajo. El costo obvio es que introduce inconsistencias en la base del código. Cuando realiza alguna operación X, se realiza de una manera en algunas partes del código y de una manera diferente en una parte diferente del código.
Para el segundo enfoque, ya has notado el beneficio obvio: la consistencia. El costo obvio es que tiene que concentrarse en trabajar de una manera que de otra manera hubiera abandonado hace años, y el código permanece ilegible de manera constante.
Para el tercer enfoque, el costo obvio es simplemente tener que hacer mucho más trabajo. Un costo menos obvio es que puede romper cosas que funcionaban. Esto es particularmente probable si (como suele ser el caso) el código antiguo tiene pruebas inadecuadas para garantizar que continúe funcionando correctamente. El beneficio obvio es que (suponiendo que lo hagas con éxito) tienes un código nuevo y brillante. Junto con el uso de nuevas construcciones de lenguaje, tiene la oportunidad de refactorizar el código base, que casi siempre dará mejoras en sí mismo, incluso si todavía usó el lenguaje exactamente como existía cuando se escribió, agregue nuevas construcciones que hagan que trabajo más fácil, y puede ser una gran victoria.
Sin embargo, otro punto importante: en este momento, parece que este módulo ha tenido un mantenimiento mínimo durante mucho tiempo (a pesar de que el proyecto en general se está manteniendo). Eso tiende a indicar que está bastante bien escrito y relativamente libre de errores, de lo contrario, probablemente se haya sometido a más mantenimiento en el ínterin.
Esto nos lleva a otra pregunta: ¿cuál es la fuente del cambio que está haciendo ahora? Si está solucionando un pequeño error en un módulo que en general aún cumple con sus requisitos, eso indicaría que es probable que el tiempo y el esfuerzo de refactorizar todo el módulo se desperdicien en gran medida, para cuando sea necesario que alguien se meta con él de nuevo, pueden estar en aproximadamente la misma posición que usted ahora, manteniendo un código que no cumple con las expectativas "modernas".
También es posible, sin embargo, que los requisitos hayan cambiado, y estás trabajando en el código para cumplir con esos nuevos requisitos. En este caso, es muy probable que sus primeros intentos no cumplan con los requisitos actuales. También hay una posibilidad sustancialmente mayor de que los requisitos se sometan a algunas rondas de revisión antes de que se estabilicen nuevamente. Eso significa que es mucho más probable que esté haciendo un trabajo significativo en este módulo en el (relativamente) corto plazo, y es mucho más probable que realice cambios en el resto del módulo, no solo en el área que conoce. ahora. En este caso, es mucho más probable que la refactorización de todo el módulo tenga beneficios tangibles a corto plazo que justifiquen el trabajo adicional.
Si los requisitos han cambiado, es posible que también deba ver qué tipo de cambio implica, y qué está impulsando ese cambio. Por ejemplo, supongamos que estaba modificando Git para reemplazar su uso de SHA-1 con SHA-256. Este es un cambio en los requisitos, pero el alcance está claramente definido y es bastante estrecho. Una vez que haya hecho que almacene y use SHA-256 correctamente, es poco probable que encuentre otros cambios que afecten el resto de la base del código.
En la otra dirección, incluso cuando comienza pequeño y discreto, un cambio en la interfaz de usuario tiene una tendencia a aumentar, por lo que lo que comenzó como "agregar una nueva casilla de verificación a esta pantalla" termina más como: "cambiar esta IU fija para admitir plantillas definidas por el usuario, campos personalizados, esquemas de color personalizados, etc. "
Para el ejemplo anterior, probablemente tenga más sentido minimizar los cambios y errar por el lado de la coherencia. Para este último, es mucho más probable que la refactorización completa valga la pena.