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 inconsistencia 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 ha notado el beneficio obvio: consistencia. El costo obvio es que tiene que inclinarse para trabajar de maneras que de otro modo hubiera abandonado hace años, y el código sigue siendo ilegible constantemente.
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 estaban funcionando. Esto es particularmente probable si (como suele ser el caso) el código anterior tiene pruebas inadecuadas para asegurar que continúe funcionando correctamente. El beneficio obvio es que (suponiendo que lo haga con éxito) tiene un nuevo código agradable y brillante. Junto con el uso de nuevas construcciones de lenguaje, tiene la oportunidad de refactorizar la base del código, lo que casi siempre proporcionará mejoras en sí mismo, incluso si todavía usó el lenguaje exactamente como existía cuando se escribió: agregue nuevas construcciones que hagan que el trabajo más fácil, y bien 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 su conjunto se mantiene). Eso tiende a indicar que está bastante bien escrito y relativamente libre de errores; de lo contrario, probablemente habría sufrido más mantenimiento mientras tanto.
Eso lleva a otra pregunta: ¿cuál es la fuente del cambio que está haciendo ahora? Si está arreglando un pequeño error en un módulo que en general aún cumple con sus requisitos, eso indicaría que el tiempo y el esfuerzo para refactorizar todo el módulo probablemente se desperdicien en gran medida, para cuando alguien necesite meterse con nuevamente, es muy posible que estén en la misma posición que usted ahora, manteniendo un código que no cumple con las expectativas "modernas".
Sin embargo, también es posible que los requisitos hayan cambiado, y usted está 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 a corto plazo (relativamente), y es mucho más probable que realice cambios en el resto del módulo, no solo en el área que conoce bien 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 necesite ver qué tipo de cambio está involucrado 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 limitado. Una vez que haya hecho que se almacene y use SHA-256 correctamente, es poco probable que encuentre otros cambios que afecten al resto de la base de código.
En la otra dirección, incluso cuando comienza pequeño y discreto, un cambio en una interfaz de usuario tiende a aumentar, por lo que lo que comenzó como "agregar una nueva casilla de verificación a esta pantalla" termina más como: "cambie esta IU fija para admitir plantillas definidas por el usuario, campos personalizados, esquemas de colores personalizados, etc. "
Para el primer ejemplo, probablemente tenga más sentido minimizar los cambios y errar por el lado de la coherencia. Para este último, la refactorización completa es mucho más probable que valga la pena.