En algún punto todo programador necesitará refactorizar código existente. Pero antes de hacerlo por favor piensa en lo siguiente, ya que tú y otras personas podrían ahorrar una gran cantidad de tiempo (y dolor):
El mejor enfoque para la reestructuración comienza por hacer un balancedel código base existente y las pruebas escritas contra ese código. Estoayudará a entender las fortalezas y debilidades del código en su estadoactual, por lo que puedes asegurar que retienes los puntos fuertes,mientras evitas los errores. Todos pensamos que podemos hacerlo mejorque el sistema actual... hasta que terminamos con algo que no es mejor –oincluso peor– que la anterior encarnación, debido a que fallamos enaprender de los errores existentes en el sistema.Evita la tentación de volver a escribir todo. Es mejor reusar tantocódigo como sea posible. No importa que tan feo sea el código, ya hasido probado, revisado, etcétera. Desechar el código viejo–especialmente si está en producción– significa que estás desechandomeses (o años) de pruebas sobre el aguerrido código que podría habertenido ciertos atajos y correcciones críticas de errores de los cualesno estás enterado. Si no tomas esto en cuenta, el nuevo código que seescriba podría terminar mostrando el mismo error misterioso que fuereparado en el código antiguo. Esto desperdiciará un montón de tiempo,esfuerzo y conocimiento adquiridos a través de los años.Muchos cambios incrementales son mejores que un cambio masivo. Loscambios incrementales permiten medir el impacto en el sistema másfácilmente a través de la retroalimentación, como las pruebas. No esdivertido ver cientos de pruebas fallidas después de realizar un cambio.Esto puede conducir a la frustración y presión que puede, a su vez, darlugar a malas decisiones. Un par de pruebas fallidas es fácil de manejary provee un enfoque más manejable.Después de cada iteración es importante asegurar que las pruebasexistentes pasan. Agrega nuevas pruebas si las pruebas existentes no sonsuficientes para cubrir los cambios realizados. No deseches las pruebasdel código antiguo sin la debida consideración. En la superficie algunasde estas pruebas podrían no parecer aplicables a tu nuevo diseño, peroserá de utilidad el esfuerzo de investigación a fondo de las razones porlas cuales estas pruebas en particular fueron añadidas.Las preferencias personales y el ego no deben ponerse en el camino. Sialgo no está roto, ¿para qué arreglarlo? Que el estilo o la estructuradel código no se ajuste a tus preferencias personales no es una razónválida para reestructurarlo. Pesar que podrías hacer un mejor trabajoque el programador previo no es una razón válida tampoco.La nueva tecnología es razón insuficiente para refactorizar. Una de laspeores razones para refactorizar se debe a que el código actual está muypor detrás de las buenas tecnologías que tenemos hoy en día, y creemosque un nuevo lenguaje o framework puede hacer las cosas mucho máselegantemente. A menos que un análisis de costo-beneficio muestre que elnuevo lenguaje o framework beneficiará la funcionalidad, mantenimiento oproductividad, es mejor dejar las cosas como están.Recuerda que los humanos cometen errores. Reestructurar no siempregarantiza que el nuevo código será mejor o tan bueno como el intentoanterior. He visto y sido parte de muchos intentos de reestructuraciónfallidos. No fue bonito, pero fue humano.
