¿Cuál es la mejor manera de refactorizar un sistema en funcionamiento?

Respuesta simple: piense dos veces y luego … piense de nuevo … y luego piense de nuevo.

Refactoré un enorme sistema de producción heredado (de 12 años) en Yahoo. Me llevó 4 meses reescribir. Un desarrollador y 2 probadores en el proyecto. El sistema estaba sirviendo a 50 millones de usuarios. La nueva base de código fue de mejor rendimiento, más escalable y mantenible. Pero el despliegue de producción se retrasó por múltiples retrocesos y abarcó 5 meses. He aquí por qué … Falta de pruebas unitarias completas …

Necesita pruebas unitarias para todos los casos de esquina posibles. No había documentación del conjunto de características original. Revisé cada línea de código antes de comenzar la refactorización. Pero durante un período de tiempo, el código se agrega al sistema sin las pruebas unitarias apropiadas. Si refactoriza el código sin un conjunto de pruebas de unidad sólido, TENDRÁ a soltar ciertas funciones que no parecen ser necesarias. En un caso, el nuevo sistema funcionó bien para la mayoría de los servidores de EE. UU. / Reino Unido, pero algunas características extrañas fallaron para los usuarios coreanos. Hasta que nos desplegamos en Corea no pudimos determinar la importancia de esa característica. Y hubo muchos otros casos extremos como este.

El sistema debe ser refactorizado de vez en cuando … Pero sería mejor trabajar en un conjunto completo de pruebas del sistema antes de comenzar a refactorizar … A menos que tenga un sistema completo y pruebas de unidades funcionales, no intente refactorizar el código especialmente orientada al cliente. Debe detectar los problemas por adelantado y no esperar a que un cliente lo informe.

Una reescritura completa del código probablemente te llevará al menos el doble de tu tiempo de estimación (así que, por mucho tiempo que creas que te llevará, duplicarlo, y esa es una estimación optimista). Es extremadamente arriesgado y propenso a errores. ¿Realmente desea relanzar todo de una vez y arriesgarse a perder decenas o cientos de errores / funciones?

Comenzaría dividiéndolo como sea posible, ya sea módulos, características, clases, etc., lo que tenga más sentido. Luego, comience averiguando exactamente qué hace cada parte del código (módulo, clase, lo que sea) y toda la funcionalidad que lo rodea, lo que realmente significa todo .

Luego, separe todas las divisiones diferentes (como lo haya dividido) en sus propias tareas / proyectos. Ahora, para cada tarea / proyecto, trátelo como una característica y escriba pruebas unitarias como debería (antes, durante, lo que sea que haga su equipo, siempre que se haga con calidad). Mientras hace esto, debe verificar tres veces para asegurarse de que está cubriendo todas las características que deben rodear este módulo / clase / etc. Luego, vuelva a verificar tres veces.

Ahora descubra alguna forma de integrar esa división con el resto del sistema, mientras elimina el antiguo código. Ahora repita esto hasta que todas las divisiones se refactoricen, luego limpie las interfaces / integración nuevamente porque es probable que haya algún código hacky para que se integre con el sistema anterior.

Lo más importante, diviértete , porque refactorizar es realmente divertido (y sacar un montón de código refactorizado a producción puede ser una descarga de adrenalina), siempre y cuando no pierdas a todos tus clientes en el proceso.