"La optimización temprana es la causante de todos los males"

-Sir Charles Antony Richard Hoare, computador científico británico, después parafraseado por Donald Knuth en su libro El Arte de Programar Computadoras

Días atrás, mirando un documental sobre la vida del director de cine sudamericano Fabián Bielinsky, me llamó la atención algo que dijo en una entrevista. Decía que, cuando se filman escenas, usualmente pasa que una toma determinada no sale como el director inicialmente asumió que iba a ser. A veces esa escena se hace de vuelta hasta que el director consiga lo que quería, en tanto que en otras ocasiones se deja no más como salió, en la medida en que así como está queda bastante mejor que la idea original. Bielinsky concluía que el verdadero arte de hacer cine es saber decidir cuándo intentarlo de nuevo y cuando dejar lo que salió de entrada

Sorprendentemente, si así viene la mano con las películas, codificar componentes es muy parecido a filmar escenas. Siempre es posible encontrar una mejor solución a un algoritmo dado. Así que, con el sombrero de gerente en la cabeza, tenemos que decidir cuándo congelar una siempre posible mejora a efector del la carga GANTT, el presupuesto, las fechas de entrega y la satisfacción general del usuario, y cuándo ir por más

Y es acá donde enfrentamos la necesidad de refactorización: una serie de técnicas y mecanismos para mejorar la calidad -comprensibilidad, mantenibilidad, modularidad, extensibilidad, etc- de segmentos de código mediante la reformulación de sus sentencias en una forma en que la conducta general no cambie. En otras palabras, el comportamiento de los componentes afectados no debería variar como una consecuencia del proceso pero su calidad, y ojalá su vida útil, debería ser incrementada

La experiencia ha mostrado que algunas porciones de nuestro código van a ser, a la corta o a la larga, candidatas a refactorización, y las razones son varias:

• Del lado del usuario, los usuarios no están completamente seguros de la aplicación que quieren hasta que ven instalado y corriendo lo que ellos pidieron originalmente. No es chiste! Al principio empiezan requiriendo algo que tienen en la cabeza pero vagamente (y eso es natural: de ninguna manera los estoy acusando). Olvidarse situaciones especiales cuando nos describen un caso de uso es como tener caries: no digo que sea bueno pero sí que es algo normal. Un efecto secundario indeseable de este tira y afloja es que nuestro código podría empezar a perder cierto grado de cohesión; sus diversos módulos pueden empezar a acoplarse arriba de los niveles aceptables como consecuencia de cambios de último minuto debidos a presiones del time to market
• De nuestra perspectiva, la del desarrollo de software, nosotros no tenemos una idea cabal de a qué el código se va a parecer mientras estamos modelando. Al igual que los usuarios, nosotros también creémos que tenemos unas ideas impresionantes (o al menos buenas ideas al fin) hasta que tratemos de poner algunas de ellas en práctica. Equivocarse no es malo. Lo que es malo es obsecarse en cambiar de parecer sólo para evitar admitir que lo que habíamos considerado una gran idea no era, de hecho, tan fácil de implementar. Y acá de nuevo, cuando el tiempo agrega su presión, entregar un componente lo más rápido que podamos puede también dañar su calidad
• Del lado de la tecnología, finalmente, hay una presión invisible aunque algo omnipresente a acompañar las tendencias de la industria. Ejemplos típicos son las APIs evolucionadas de .NET o Java (AJAX, servicios web, etc) que tornan obsoletas a las versiones previas, o estrategias generales como Arquitectura Orientada a Servicios (SOA), Modelo-Vista-Controlador (MVC), Mapeo entre Objetos y Relaciones (O/R-M), etc. Una vez más, en la medida en que reaccionamos a estas tendencias nuestro código es sometido a cierta manipulación que, a medida que el tiempo pasa, puede erosionar su calidad

Mientras tanto, el mundo real nos muestra que esmerarnos en mejorar la calidad de nuestro código es algo que tendemos a hacer en forma innata. Las técnicas de refactorización no son sino el más alto grado de maduración de esos intentos espontáneos, reforzadas con algunas herramientas de soporte disponibles por ahí para garantizar el éxito del proceso

La buena noticia es que podemos aplicar refactorización localmente, al nivel de un componente o método, allí donde estemos aplicando cualquier otra modificación; o globalmente, a nivel de módulo o aplicación, asignándole rango de proyecto. Decidir la dosis correcta de refactorización dependerá de la brecha de calidad a cerrar, el tiempo restante, el presupuesto disponible (siempre será más fácil justificar la refactorización donde ya teníamos algo más que hacer que donde ninguna actualización había sido pedida aún), entre otros factores

A lo largo de este libro, el autor abordará tópicos de refactorización desde la visión de sus beneficios a las maneras actuales de ponerlo en práctica. Danijel Arsenovski ha estado involucrado en técnicas de refactorización, tanto en las plataformas .NET como Java, desde sus versiones más tempranas. Dio varias conferencias, charlas y talleres en esta materia, dirigiendo proyectos exitosos de refactorización en la industria bancaria

Como uno de los líderes en herramientas de desarrollo, Microsoft ha estado comprometido a distribuir los mejores recursos para la gente que día a día lidia con actividades de codificación y proyectos de software en su totalidad. Mediante su indiscutidamente ganador entorno integrado Visual Studio, Microsoft hace de la refactorización una facilidad out-of-box apenas a un click de distancia de tu código. A lo largo de las páginas de este libro, Danijel te mostrará cómo la refactorización puede ser practicada en Visual Basic tan fácil como hacer copy / paste o cualquier otra actividad de edición!

Me atrevo a decirte, estimado, que vas a encontrar en este libro una de las guías más probadas y fundamentales en estas técnicas. Que disfrutes este libro!

Diego Dagum
Evangelista Técnico, Microsoft Corp.
Kingsgate, Invierno de 2007

(Lo que acabás de leer es el prólogo que escribí para el libro de Danija "Professional Refactoring in Visual Basic" - Ediciones Wrox)