Refactorización: un prefacio al trabajo de mejorar el diseño del código existente.

La primera vez que escuché la palabra "reconstrucción" fue en 2001. La idea de ello me sorprendió en ese momento. El software tiene sus propios beneficios. La ingeniería de software espera establecer requisitos y diseños completos y escribir código estandarizado de acuerdo con las especificaciones existentes. Esta es la belleza de la iteración rápida y el descifrado, subvertir el mito de "omnisciente y omnipotente" y resolver problemas de una manera casi milagrosa. Caos: implementar requisitos en un ciclo, esta es la belleza de la deconstrucción; Kent Beck y Martin Fowler se unieron y utilizaron la metodología ágil y rigurosa de XP para explicar la belleza de la reconstrucción; no sé quién la puso originalmente. Se traduce como "reconstrucción", pero se convierte en el toque final.

Siempre he sido un fan de los patrones de diseño. En mi opinión, el desarrollo de software debería tener una "utopía"; por supuesto, en esta utopía, no son los filósofos sino los modelos quienes mantienen el orden perfecto. Los patrones de diseño no sólo nos brindan soluciones a algunos problemas específicos, sino también el deseo de perseguir una "racionalidad" perfecta. Sin embargo, Joshua Kerievsky señaló claramente en su famoso artículo "Patrones y XP" (recopilado en el libro "Extreme Programming Research") que el uso de patrones en las primeras etapas del diseño a menudo conduce a una ingeniería excesiva. Esta es una cruel realidad. Es imposible escribir código práctico simplemente buscando la perfección, y la "practicidad" es el elemento primordial del software. A partir del artículo "Stop Overengineering", Kerievsky escribió una serie de artículos "Refactorización de patrones". Este judío, con su sabiduría nacional, descubrió con entusiasmo el camino postestructuralista del software. Lo que hace que los patrones de diseño vuelvan a brillar en la siempre cambiante era de Internet es el poder de la reconstrucción.

En una publicación de amplia circulación, alguien enumeró los patrones de diseño y refactorización como la "biblia de la industria Java". En mi opinión, esta yuxtaposición en realidad no es exacta. De hecho, aunque me encantó el libro Reconstrucción, no lo he leído desde que fue traducido. No, no porque me lo sepa de memoria, sino porque la reconstrucción se ha convertido para mí en otra forma de vida, en mi pan de cada día, y en el aire y el agua de todo nuestro equipo, hasta el punto de que no necesito buscar cualquier cosa en el libro. En cuanto a "Patrones de diseño", siempre lo tengo a mano porque no siempre lo recuerdo tan vívidamente.