Como director de desarrollo de software, usted acaba de heredar una gran base de código y todo el mundo espera que presente nuevas funciones cruciales. Preferentemente, para ayer.
Te encantaría hacerlo. Pero ni usted ni su equipo entienden el código. ¿Podría ayudarte la refactorización del código? La refactorización de código en Ágil está de moda, después de todo. Se dice que es lo que hace que los equipos puedan responder rápidamente a los cambios. Y eso es exactamente lo que necesitas.
Pero ni tú ni tu equipo tenéis experiencia en ello. Lo que buscas es un buen comienzo, entender los fundamentos y recibir orientación sobre cómo practicarlo. Pues estás en el lugar adecuado.
Este artículo te equipará con los fundamentos adecuados, de modo que pronto estarás bien encaminado para refactorizar la base de código existente y añadir nuevas características.
Con el tiempo, el diseño del software tiende a degradarse y los sistemas se vuelven cada vez más difíciles de cambiar.
La refactorización del código tiene como objetivo evitar que el software se degrade o, cuando ya se ha degradado, mejorar su diseño para que sea más fácil de entender y cambiar.
La refactorización del código es importante para eliminar los defectos de diseño, lograr la mantenibilidad y la extensibilidad de un sistema de software.
Lo más importante es que la refactorización de código cambia el diseño del código, pero nunca el comportamiento del software. Nunca se mezclarán los dos.
La refactorización no fue un accidente feliz.
Los programadores han limpiado, reorganizado y reestructurado su código instintivamente desde que se escribieron los primeros programas.
A finales de la década de 1980, dos estudiantes de posgrado de informática de la época (William Opdyke en la Universidad de Illinois en Urbana-Champaign y William Griswold en la Universidad de Washington), inventaron de forma independiente lo que ahora se llama refactorización de software.
Con el tiempo, el diseño del software tiende a degradarse y los sistemas se vuelven cada vez más difíciles de cambiar.
La refactorización del código tiene como objetivo evitar que el software se degrade o, cuando ya se ha degradado, mejorar su diseño para que sea más fácil de entender y cambiar.
La refactorización del código es importante para eliminar los defectos de diseño, lograr la mantenibilidad y la extensibilidad de un sistema de software.
Lo más importante es que la refactorización de código cambia el diseño del código, pero nunca el comportamiento del software. Nunca se mezclarán los dos.
La refactorización no fue un accidente feliz.
Los programadores han limpiado, reorganizado y reestructurado su código instintivamente desde que se escribieron los primeros programas.
A finales de la década de 1980, dos estudiantes de posgrado de informática de la época (William Opdyke en la Universidad de Illinois en Urbana-Champaign y William Griswold en la Universidad de Washington), inventaron de forma independiente lo que ahora se llama refactorización de software.
He aquí una breve evolución de la refactorización:
Investigador | William Griswold
| William Opdyke
|
Enfoque de la investigación | Evolución del software Una vez desplegadas las aplicaciones, ya no se pueden modificar. | Cambio de software Incluye la ingeniería de software basada en el conocimiento, la transformación de programas y la evolución del esquema de la base de datos. |
Influencia temprana | 1987:
1988:
| 1986:
1990:
|
Conductor clave | ¿Cómo construir una herramienta para apoyar la reestructuración que preserva el significado? | Cómo programar operaciones de reestructuración (refactorizaciones) que apoyen el diseño, la evolución y la reutilización de los marcos de aplicación orientados a objetos. |
Contribuciones clave |
|
|
Refactorizar el código es cambiar el código con dos restricciones cruciales:
Esta segunda restricción merece ser repetida: una refactorización nunca debe cambiar el comportamiento de un programa. Esto significa que si el programa se ejecuta antes y después de una refactorización con el mismo conjunto de entradas, el conjunto de valores de salida resultante será el mismo.
También oirás hablar de refactorización como sustantivo y como verbo. Y aquí tienes una definición rápida.
Refactoring (sustantivo): un cambio realizado en la estructura interna del software para hacerlo más fácil de entender y más barato de modificar sin cambiar su comportamiento observable.
Refactorizar (verbo): reestructurar el software aplicando una serie de refactorizaciones sin cambiar su comportamiento observable..
Si el código funciona, ¿la refactorización no es una operación de oro? ¿Una pérdida de tiempo? ¿Un ejercicio mental para seguir facturando por horas? ¿Un entretenimiento para intentar que su código sea el mejor desde un punto de vista purista, o hay un valor real en hacerlo?
Resulta que la refactorización es la forma de mejorar el diseño y la calidad de tu código. Y si se deja de trabajar en el código en cuanto parece que funciona, es muy probable que no se adapte bien a futuros cambios. Y, por tanto, los cambios futuros serán más caros.
Sin el cuidado adecuado, el coste de cambiar una aplicación puede aumentar exponencialmente en proporción a su tamaño y complejidad. Con el tiempo, puede dejar de ser rentable seguir actualizando la aplicación.
La refactorización ayuda a garantizar que el código liberado sea fácil de mantener. Como dice el refrán: «Una puntada a tiempo ahorra nueve», la refactorización a tiempo facilita y abarata la incorporación de nuevas funcionalidades.
Si su sistema tiene mucha deuda técnica, ¿debería dejar de trabajar en nuevas funcionalidades y dedicar unas semanas a la refactorización? A veces esto puede tener sentido, pero hay ciertos problemas con esta estrategia.
Ilustremos esto con una analogía:
Imagine que es un chef en un restaurante de lujo. Usted ha estado en el negocio durante seis meses, y ha establecido algunos clientes regulares. Sin embargo, ha estado muy ocupado y ha dejado de lado la limpieza. El estado de su cocina y de sus ollas y sartenes interfiere en su capacidad para ofrecer comidas de buen sabor antes de que sus clientes se impacienten y se marchen.
Después de unos cuantos sustos y una visita del inspector de sanidad, es hora de que depure la cocina, por así decirlo. Pero no puede cerrar su restaurante durante unas semanas mientras lo limpia todo, ¿verdad? Puede que sus clientes habituales lo toleren, pero no está garantizado y seguro que perderá muchos negocios de los transeúntes ocasionales.
Lo mismo ocurre con el desarrollo de software.
Detener las operaciones, la creación de valor con características nuevas o mejoradas, es poco probable que vaya bien con su cliente, las partes interesadas y los gerentes.
Los buenos restaurantes no funcionan así. No dejan que los problemas de limpieza se queden sin revisar hasta el punto de tener que cerrar. Nótese que he dicho buenos restaurantes. Hacen de la limpieza y el mantenimiento una parte habitual de sus operaciones.
Y, de nuevo, lo mismo se aplica al desarrollo de software.
La refactorización regular del código es como la limpieza de la cocina. Es mucho más eficaz para mantener la capacidad de responder a nuevos requisitos y ofrecer valor a sus usuarios o clientes.
Hay momentos en los que no se debe refactorizar.
La refactorización nunca debe cambiar el comportamiento del código.
Esto significa que debe ser capaz de verificar el comportamiento de tu código. Todo su código, no sólo las partes que ha cambiado.
Por lo tanto, no puede, y ni siquiera quiere refactorizar, cuando:
Kent Beck acuñó el término code smells en la década de 1990. Los olores de código son síntomas, o señales, en el código fuente de un programa que indican un problema potencialmente más profundo.
En su libro seminal «Refactoring», Martin Fowler da una definición similar: «Un olor a código es una señal superficial que suele corresponder a un problema más profundo en el sistema».
Los olores de código no son errores.
El código es correcto y el programa funciona como debería.
En cambio, muestran debilidades en el diseño del código que pueden ralentizar el desarrollo o aumentar el riesgo de errores o fallos en el futuro.
Un ejemplo de olor a código es el «Código duplicado»: el mismo código copiado y pegado en varios lugares. Es sólo cuestión de tiempo que alguien se olvide de cambiar una de esas copias junto con sus hermanos.
La refactorización que hay que aplicar para desodorizar este olor es el «Método de Extracción»: fusionar las copias en una función o un método de la clase.
Debido a que los olores de código son «problemas esperando a ocurrir» es bueno esforzarse por conseguir cero olores de código.
Para minimizar la probabilidad de que introduzca accidentalmente errores como parte de su refactorización, debe seguir un proceso estricto.
No lo es. Nunca he oído que sea peligroso.
Sin embargo, hay algunos errores que podrías cometer:
La refactorización no es más peligrosa que cualquier otra práctica de codificación, en realidad. Hay que ser consciente de lo que puede salir mal y tomar medidas para evitarlo.
Tiene un fragmento de código que se puede agrupar.
————————————————–
void PrintOwing()
{
this.PrintBanner();
// Print details.
Console.WriteLine(“name: ” + this.name);
Console.WriteLine(“amount:”+ this.GetOutstanding());
}
————————————————–
Mueva este código a un nuevo método (o función) independiente y sustituya el código antiguo por una llamada al método.
————————————————–
void PrintOwing()
{
this.PrintBanner();
this.PrintDetails();
}
void PrintDetails()
{
Console.WriteLine(“name: ” + this.name);
Console.WriteLine(“amount: ” + this.GetOutstanding());
}
————————————————–
¿Recuerda ese código base que heredó? ¿La que ni usted ni su equipo entienden? ¿Que le hizo preguntarse cómo cumplir con las expectativas de todos en cuanto a nuevas características?
Ahora ya sabe cómo abordar esa base de código con confianza.
Si hay pocas o ninguna prueba, el primer paso es crear un Golden Master.
Cuando tenga ese Golden Master, o si tiene la suerte de que el código base tenga una buena cobertura de pruebas, puede proceder a la refactorización para facilitar la adición de nuevas características, y a la adición de esas nuevas características. Todo ello sin cerrar el negocio.
Así que, adelante, empieza a refactorizar y a añadir las características que todo el mundo está esperando.