En la mitología griega, Sísifo era un pobre sujeto que se veía condenado, por circunstancias que no vienen al caso, a realizar el peor trabajo del mundo: tenía que empujar una enorme piedra cuesta arriba de una ladera. Y siempre que llegaba a la cima, la piedra rodaba cuesta abajo y el desgraciado debía volver a empezar. Constante e interminablemente. Sin sentido, debía repetir el mismo exacto trabajo cada vez.
La razón por la que lo califico (y seguro que no sólo yo) de peor trabajo se encuentra primero que nada en una cuestión de fondo: ¿quién querría repetir a cada rato el mismo trabajo una y otra vez? ¿qué sentido tendría eso? Hasta el barrendero que debe limpiar siempre las mismas calles barre siempre basura diferente. Así que una misma y exacta tarea repetida múltiples veces no arrojan nada, ni siquiera sentido. Todos buscamos, algunos más en el fondo que otros, que aquello que hacemos tenga algún sentido, algún propósito. En ese sentido podemos calificar al trabajo de Sísifo no solamente de lo peor, sino también de inhumano.
Pero también hay otra razón por la que Sísifo tiene el peor trabajo. ¿Qué más quisiera uno dedicar sus esfuerzos a cosas nuevas, y relegar las viejas a la rutina, que se hagan de manera casi-automática, sin tener que esforzarnos (física o mentalmente) una y otra vez con ellas? Una vez hecho un trabajo y logrado un hito, queremos pasar página. Y sí, construir sobre lo que ya logramos, pero no repetir una y otra vez el mismo esfuerzo.
¡No Te Repitas!
En el diseño y desarrollo de software existe un principio muy bien establecido como buena práctica en la industria que precisamente busca evitar estar realizando el peor trabajo del mundo.
El principio se conoce, por sus siglas en inglés, como DRY (Don't Repeat Yourself), y busca precisamente anular las repeticiones, inútiles y hasta peligrosas, en el código de un sistema.
Imagina que debes implementar una funcionalidad muy común en distintos módulos (porque al menos haces módulos ¿no? ¡ni que ésto fuera la edad de piedra!) de un sistema. Digamos... enviar un email al usuario bajo distintas circunstancias. Puede ser que en cierta parte lo haga para avisarle de un error en un proceso. En otra para darle un resumen de operaciones diarios. En otra quizá un reporte final cuando cierta operación ocurre. Es algo MUY común.
Ahora imagina que las reglas para el envío de email desde el sistema incluyen algunas rarezas como éstas:
- Además del destinatario en cuestión, cada email debe ir copiado a una direccion de correo específico, un administrador por ejemplo.
- El subject del correo debe incluir el nombre del módulo que lo está enviando.
- Al inicio del cuerpo del correo, a manera de carta, debe haber un texto que indique la fecha y el lugar geográfico desde donde el usuario generó el proceso que envía el correo, o si se trata de un proceso en segundo plano debe dar la dirección de las oficinas centrales de la compañía...
Hasta ahí, nada fuera de los cánones de rarezas que nos suelen pedir a los de sistemas...
Pero ahora imagina que esta funcionalidad del correo electrónico fue creada por un programador poco diestro en su arte (o peor aún, un equipo de ellos).
Así que escribió la función de envío de correo en el módulo de errores del sistema, de forma que fuera llamado cuando ocurría un error en el sistema.
Y luego, aprovechando que ya sabía cómo, escribió justo el mismo código (o mejor aún, copió y pegó) en el módulo que genera resúmenes diarios para los altos ejecutivos de la organización. Y como es una buena persona (aunque fuera mal programador), le pasó su código a otro compañero que debía implementar el envío de emails al finalizar ciertas operaciones del sistema que estaba implementando. Claro que él le hizo una pequeña mejora al código porque el original tenía un problema, pero él aunque también buena persona era más distraído (la verdad es que programar no era lo suyo) y nunca comunicó sus mejoras al buen samaritano que le pasó el código.
El caso es que, verbatim, el mismo código quedó desperdigado por varios lugares del sistema. No parece haber mayor problema, puesto que el módulo fue probado muchísimas veces por nuestro programador, y también por su compañero que recibió la copia. Y una vez liberado, millones de veces en uso demostraron que el código funcionaba sin ninguna falla.
Nuestros incautos programadores siguieron sus vidas, quizá uno de ellos fue despedido por ser tan malo pero eso le enseñó a ser mejor y cometió menos errores en el futuro. Quizá el otro, como dijimos antes, terminó decidiendo que programar no era lo suyo y terminó dedicándose a, qué se yo, alguna labor administrativa detrás de un escritorio.
Y llegaron nuevos programadores a darle mantenimiento al sistema. Y por supuesto, los sistemas, que son como seres vivos, crecieron y evolucionaron, y junto con ellos sus requerimientos. Así que un nuevo jefe decidió que ese envío de correos estaba mal. En principio el subject no debía incluir el módulo que generó el correo, eso debía ir al pie del cuerpo del correo. Además la dirección del administrador ya había cambiado, en lugar de fulanito.sysadmin@miempresita.com, debía ir dirigido a una lista de correos de SysAdmins de toda la empresa. ¿Y eso de que el correo pareciera una carta? Una bobada, había que eliminarlo. Y encima, ¡se descubrió una vulnerabilidad en el funcionamiento! Había que corregirla...
¡No se repitan!
Así que se le encomendó a los nuevos programadores la labor de que todos estos correos fueran enviados bajo las nuevas políticas. ¿Qué creen que pasó al final del cuento? Además de que seguramente le zumbaron los oídos a los desdichados e inexpertos que ya tenían otra vida fuera de ese lugar.
Afortunadamente, los nuevos programadores hicieron lo que se debió hacer desde un principio:
Abstraer todo el funcionamiento de envío de correos a un lugar común, parametrizarlo, y luego ir a donde estaba todo el código repetido y solamente mandar llamar el código del lugar común. Y cuando hubiera cambios, sólo se harían en UN SÓLO LUGAR. Y cuando hubiera errores se corregirían en UN SÓLO LUGAR. Sin repeticiones. Sin torturas griegas.
En eso consiste el principio DRY, tienes un código, y tienes PROHIBIDO repetirlo, debes ser lo suficientemente ingenioso para acomodarlo de forma que NADIE tenga que repetirlo otra vez.
