Estás tocando el código de un compañero o tuyo de hace un tiempo. Encuentras lo que querías modificar, lo cambias y no surte efecto. Puede deberse a muchos factores, uno de ellos podría ser que estés editando código repetido. Sobre eso va el principio DRY en programación.
Don’t repeat yourself
El principio tiene su origen en el libro The Pragmatic Programmer, de Andy Hunt y Dave Thomas.
Tampoco hay que ser dogmático, no es algo que se tenga que seguir sí o sí siempre. Pero es una buena idea tenerlo en mente y cuestionar en cada caso si es necesario cambiar algo para evitar repetir fragmentos. ¿Por qué? pues he aquí una lista.
- Es más sencillo. Sobre todo para el que tenga que tocar tu código después o cuándo hay que encontrar y corregir errores.
- Una persona que no conozca en profundidad el proyecto, debería poder encontrar el fragmento y editarlo, dando por supuesto que no tendrá que repetirlo en otros lugares.
- Las inconsistencias. Imagina el lío que supone cuando corriges algo en un punto y no recuerdas que había que hacerlo en otros.
- Ahorrar tiempo. Quizá no de primeras, pero sí a la larga. Un código que sólo está en un lugar, sólo se tiene que mantener una vez.
- Margen de error. Si no escribes un código, no introducirás errores con él. Cuando digo esto suele parecer gracioso, pero no por ello es menos cierto.
Si te fijas, las ventajas suelen tener que ver con el mantenimiento de código más que con la creación de él. Se debe a que en efecto cuando se está trabajando, lo que se hace un gran porcentaje del tiempo es eso, mantener.
¿Cómo se consigue un código DRY?
Si estás escribiendo código procedural lo tienes un poco más difícil, pero no imposible. Puedes por ejemplo usar funciones que te ayuden a encapsular fragmentos y reutilizarlos así.
Si por el contrario estás usando objetos, la forma más fácil de conseguirlo es sencillamente usar bien los objetos; me explico: Cuando una clase hereda otra lo que está haciendo es precisamente no repetir todos los métodos y propiedades que hereda de ella. Incluso los métodos que se definen en cada clase son una forma de no repetir esos bloques de código. Un uso pobr de los objetos sería, por ejemplo, dejar todo el código en el constructor de la clase. Perderíamos sus ventajas y con ello el DRY, no suena nada bien.
La importancia de nombrar
Solo hay dos cosas difíciles en las Ciencias de la Computación: la invalidación de caché y poner nombre a las cosas.
— Phil Karlton, 1947 – 1997
Aunque a veces no lo parezca, poner nombres suele ser una de las tareas más complejas. Para el caso que nos ocupa, puede ser la diferencia entre un código WET o DRY, por ejemplo:
Teniendo estos arrays de ejemplo:
const frutas = ['pera', 'manzana', 'plátano', 'uva'];
const hortalizas = ['brócoli', 'calabacín', 'guisante', 'acelga'];
const tuberculos = ['chufa', 'jengibre', 'rábano', 'remolacha'];
Ejemplo WET
function logFrutas (frutas) {
frutas.forEach((fruta) => {
console.log(fruta);
});
}
logFrutas(frutas);
logFrutas(hortalizas); // 👎 No parece tener sentido
logFrutas(tuberculos); // 👎 No parece tener sentido
Ejemplo DRY
function logItems (...arrays) {
arrays.forEach((array) => {
array.forEach((item) => {
console.log(item);
});
});
}
logItems(frutas, hortalizas, tuberculos); // 👏 Una sola línea
En el primer ejemplo, no sólo no tenga mucho sentido a nivel lingüístico, es que para conseguir que lo tenga deberíamos triplicar logFrutas y tener otros métodos que hagan lo mismo pero se llamen logHortalizas y logTuberculos. En este ejemplo puede no parecer grave, pero cuando logItems se encarga de cosas complejas y en lugar de estar uno junto a otro está distribuido en diferentes ficheros sí lo es.
Conclusión
No siempre es fácil ver oportunidades para convertir código WET en DRY. Creo que nombrar bien las cosas es un buen ejercicio en general y aunque es casi tan complicado como necesario, nos ayuda a abstraer mejor el código, haciendo que sea más reutilizable.