"Antes de ti, refactoriza"

Consejos de programación para #programadores.

-----------------------------------------------------------------------

LIBRO: 97 COSAS QUE TODO PROGRAMADOR NECESITA SABER.

POR: KEVLIN HENNEY.

-----------------------------------------------------------------------

6° "ANTES DE TI, REFACTORIZA":

En algún momento, cada programador deberá refactorizar el código existente. Pero antes de hacerlo, piensa en lo siguiente. Ya que ésto podría salvar a ti y otros mucho tiempo (y dolor).

• El mejor enfoque para la reestructuración comienza haciendo un balance del código base y las pruebas escritas contra ése código. Ésto te ayudará a comprender las fortalezas y debilidades del código tal como está actualmente para que puedas asegurarte de conservar los puntos fuertes mientras evitas los errores. Todos pensamos que podemos hacerlo mejor que el sistema existente hasta que terminamos con algo no mejor, o incluso peor, que la anterior encarnación porque no supimos aprender de los errores del sistema existente.

• Evita la tentación de reescribir todo. Lo mejor es reutilizar tanto código como sea posible por muy feo que sea el código, ya ha sido probado, revisado, etc. Tirar el código antiguo especialmente si fue en producción—significa que está desperdiciando meses (o años) de código probado y endurecido en batalla que puede haber tenido ciertas soluciones y correcciones de errores que no conoces. Si no tienes esto en cuenta, el nuevo código que escriba puede terminar mostrando los mismos errores misteriosos que fueron corregidos en el código antiguo. Ésto desperdiciará mucho tiempo, esfuerzo y conocimiento ganado a lo largo de los años.

• Muchos cambios incrementales son mejores que un cambio masivo. Los cambios incrementales le permiten medir el impacto en el sistema más fácilmente a través de la retroalimentación, como de las pruebas. No es divertido ver cien pruebas fallidas después de hacer un cambio. Esto puede conducir a la frustración y la presión que a su vez puede resultar en malas decisiones. Un par de fallas de prueba a la vez es más fácil de tratar, lo que lleva a un enfoque más manejable.

• Después de cada iteración de desarrollo, es importante asegurarse de que pasan las pruebas. Agregar nuevas pruebas si las pruebas existentes no son suficientes para cubrir los cambios que hiciste. No deseche las pruebas del código anterior sin la debida consideración. En la superficie, algunas de éstas pruebas pueden no aparecer aplicable a su nuevo diseño, pero valdría la pena el esfuerzo para profundizar en las razones por las que se agregó esta prueba en particular.

• Las preferencias personales y el ego no deben interponerse en el camino. si algo no está roto, ¿por qué arreglarlo? Que el estilo o la estructura del código no cumplen con sus preferencias personales no es una razón válida para la reestructuración. Pensar que podrías hacer un mejor trabajo que el programador anterior no es una razón válida tampoco.

• La nueva tecnología es una razón insuficiente para refactorizar. Una de las peores razones para refactorizar es porque el código actual está muy por detrás de toda la tecnología genial que tenemos hoy, y creemos que un nuevo lenguaje o marco puede hacer las cosas con mucha más elegancia. A menos que un análisis de costo-beneficio muestre que un nuevo lenguaje o marco resultará en mejoras significativas en funcionalidad, mantenibilidad o productividad, es mejor dejarlo como está.

• Recuerda que los humanos cometemos errores. La reestructuración no siempre garantiza de que el nuevo código será mejor, o incluso tan bueno como el intento anterior. He visto y he sido parte de varios intentos de reestructuraciones fallidas.

No era bonito, pero era humano.

-Rajith Attapattu-