Al refactorizar un código se modifica de forma que sea más legible y se eviten futuros problemas.
Por ejemplo, algo como:
int precio(int a) {
int p;
if(a < 10) {
p = 0;
} else if(a >= 10 or a < 20) {
p = 10;
} else {
p = 20;
}
return p;
}
Se puede transformar a:
int precio(int edad) {
if(edad>=20)
return 20;
if(edad < 10)
return 0;
// Edad entre 10 y 20:
return 10;
}
El código final es más corto y legible. Las técnicas que se usan para refactorizar están más que descritas en la literatura.
Por casualidad me encontré con:
En esta página hay un resumen de las técnicas de refactorización y también se puede encontrar otro resumen de patrones de diseño.
En el ejemplo anterior se ha renombrado una variable. También se ha usado:
https://refactoring.guru/remove-assignments-to-parameters
Se ha intentado usar:
https://refactoring.guru/replace-nested-conditional-with-guard-clauses
pero se ha visto que reordenando los condicionales, se podía eliminar un condicional y sustituirlo por un comentario.
Es buena idea ponerse el siguiente enlace en favoritos y visitarlo leyendo una técnica al azar de vez en cuando:
https://refactoring.guru/refactoring/techniques
Hay que tener en cuenta que la refactorización trata de mejorar la legibilidad del código, no de hacerlo más corto u óptimo. Puede suceder que después de refactorizar haya más código. También podría ocurrir que el rendimiento mejore o empeore.
Patrones de diseño
Imagina que un arquitecto va a construir una casa. Hay una serie de técnicas y métodos que usará que otros arquitectos ya han comprobado a lo largo de la historia que funcionan y le ahorrarán problemas a largo plazo. Por ejemplo, usará vigas de hormigón en lugar de arcos de medio punto y bóvedas de cañón.
Los patrones de diseño se podrían asimilar a dichas técnicas. Por ejemplo, si tienes una biblioteca muy compleja de usar, pero sabes que hay una determinada característica que se va a usar mucho, se puede crear una función que simplifique el uso de esa característica. Esto es un patrón de diseño (facade):
https://refactoring.guru/design-patterns/facade
Otro patrón es «singleton». Imagina que en un código necesitas hacer una conexión a un recurso que cuesta mucho realizar. Una vez conectado, compensa compartir la conexión dentro de nuestro código. Si el proyecto es muy grande y trabajan muchas personas en él, se corre el peligro de volver a realizar otra conexión al recurso en otro lugar. Singleton propone crear una función que sea la encargada de conectar con el recurso y siempre devolverá el objeto ya creado de forma que no se repita el proceso de conexión. Merece la pena ver la descripción que se hace en «refactoring.guru»:
https://refactoring.guru/design-patterns/singleton
También merece la pena ponerse el siguiente enlace en favoritos y visitar los patrones al azar:
https://refactoring.guru/design-patterns/catalog
Espero que os sea útil.
Cartas de Linux 