WP - Consejos de programación 1 - Don’t be WET, stay DRY
En esta ocasión quiero iniciar una serie de consejos de programación
que considero importantes a nivel de eficiencia, orden y -por que no
decirlo – estética. Estos consejos se basan en algunas prácticas que he
observado durante los pocos años de mi carrera. Algunas de esas
prácticas son buenas, mientras que otras son las que quisiera evitar.
También se basan en cosas interesantes que he encontrado en uno que otro
artículo por el Internet (de esos artículos donde la gente gustan
hablar de temas con acrónimos de 3 o 4 letras).
Iniciaré la serie compartiendo algo acerca del principio de
desarrollo de software conocido como DRY (inglés: seco), que significa
Don’t Repeat Yourself. Creo que ya saben más o menos por donde va la cosa, pero antes de definir el término, haré una pequeña introducción.
Introducción
Algo que he visto muchas veces es que cuando se quieren añadir nuevos
elementos a una aplicación (ventanas, controles de usuario, funciones),
y estos son muy similares a elementos ya existentes, lo que hacen los
programadores es copiar y pegar el código fuente correspondiente a
dichos elementos, y hacer las modificaciones en la copia de acuerdo a
los nuevos requerimientos. Esta técnica es vulgarmente conocida en
nuestro medio como “copy-paste”, y también es aplicable a la técnica que
usan los estudiantes cuando buscan sus tareas en Wikipedia, El Rincón
del Vago, Taringa, o Yahoo respuestas, en el peor de los casos
(aceptémoslo, todos hemos aplicado esta técnica alguna vez, jejeje…)
Considero que esta una práctica muy arraigada debido a que esto se
considera la forma más rápida de incluir nuevos elementos en una
aplicación. Pero si se analiza cuidadosamente, al final no resulta ser
la forma más rápida, porque:
- Al crear un nuevo elemento a partir de la copia de uno ya existente, implica que es necesario cambiar parte del código fuente, para cambiar o añadir la funcionalidad deseada. También hay que tener particular cuidado con aquellos parámetros que han sido “quemados” (hard-coded) dentro de la aplicación.
- El resultado es una aplicación con una gran cantidad de código fuente, lo que también deriva en la existencia de varios archivos desorganizados y desperdigados en la carpeta que contiene el proyecto.
- Si se requiere cambiar una funcionalidad principal que se ha repetido en todos los elementos copiados, esta modificación debe hacerse en cada uno de ellos.
Definición de DRY y WET
Basta de hacer catarsis, procederé a definir los conceptos más
formalmente. En la “ingeniería de software”, el término DRY, o “Don’t
Repeat Yourself”, se refiere a reducir la repetición de información de
cualquier tipo. El principio DRY dicta: “Cada pieza de conocimiento debe
tener una representación única, no ambigua y autoritaria dentro de un
sistema”. El término fue acuñado por Andy Hunt y Dave Thomas en su libro
“The Pragmatic Programmer”. Eric Raymond hace referencia a un término
equivalente, llamado SPOT (“Single Point Of Truth”) en su libro “The Art
Of Unix Programming”. Cabe destacar que el término no se limita a
código fuente ni datos, sino a un sistema cualquiera. Tampoco se refiere
necesariamente a no repetir código fuente en un sistema informático,
sino que este tenga una fuente única dentro del sistema.
El término contrario a este es WET (inglés: mojado), al cual
se le han dado muchos significados: “We Enjoy Typing”, “Write
Everything Twice”, “We Edit Terribly”, etc. Obviamente, significa que
existen “piezas de conocimiento” con múltiples representaciones, que
podría traducirse como tener la misma información repetida varias veces.
Ventajas de DRY
Ustedes se preguntarán por qué tomarse la molestia de aplicar este
principio, si han vivido felizmente con la técnica de copy-paste por
mucho tiempo, a tal punto que ya tienen práctica con la mano izquierda
para hacer las secuencias de teclas Ctrl+C y Ctrl+V. Pues bueno, las
ventajas que yo he observado de primera mano en las aplicaciones que he
visto son las siguientes:
- Toda elemento (función, método, procedimiento, clase) e información dentro de la aplicación posee un origen único, por lo que si se requiere modificar la funcionalidad principal de alguno de ellos, debe hacerse en un solo punto.
- La cantidad de código fuente se reduce.
- El desglose de funcionalidades permite el manejo de múltiples capas. Esto también permite una organización más clara de los archivos de código fuente.
- El trabajo de añadir nuevos elementos basados en elementos anteriores se reduce, ya que no implicará copiar y modificar código fuente para satisfacer los nuevos requerimientos, sino más bien reutilizar elementos y funcionalidades ya existentes. En el mejor de los casos, solo será necesario invocar los elementos ya existentes, con parámetros distintos, para obtener los resultados requeridos.
Desventajas de DRY
A pesar de todo, y como todo en esta vida, DRY posee algunas desventajas que hay que tener en cuenta:
- Muchas veces se requerirá de análisis profundo para encontrar una forma aceptable de centralizar todos los elementos de un sistema. La construcción de este kernel para la aplicación puede tomar algo de tiempo.
- En algunos casos, la solución centralizada será menos eficiente en tiempo de ejecución que la solución repetitiva. Un buen ejemplo de ello es cuando una consulta muy utilizada en una base de datos relacional (digamos de SQL Server) se coloca en una función de usuario para poderla usar varias veces. La función por si sola puede ser eficiente, pero al intentar utilizarla dentro de otras consultas, puede ser más lento y pesado que si la consulta no hiciera uso de ella.
- Dejar de lado el hábito de copy-paste, jejeje…
Cómo implementar el principio DRY
Dicho lo anterior, ahora os describiré algunas técnicas que os pueden
ayudar a implementar el concepto de DRY en vuestros programillas:
- Refinamiento del sistema en partes individuales con funcionalidades específicas y diferenciadas (técnicas top-down y bottom-up). Como me decían en la materia Programación Estructurada, “hay que reducir el problema en problemas más pequeños” (o algo así).
- Agrupar elementos y funcionalidades similares, a nivel de archivos y directorios, así como a nivel de código fuente.
- Si se observa que una funcionalidad o elemento se repite más de una vez, o bien que es son muy parecidos a otra funcionalidad o elemento existente, entonces centralizarlos en un solo lugar. Por ejemplo, en la programación orientada a objetos, si se tienen por ejemplo las clases Profesor y Estudiante con propiedades y métodos similares, lo mejor sería que los elementos comunes los heredaran de una clase padre (Persona, por ejemplo).
- En el caso de programación orientada a objectos, hacer uso de la herencia, clases abstractas, interfaces, y otros elementos que nos permiten centralizar la funcionalidad e información en clases, y hacer uso extensivo de ellas.
- Hacer uso de Frameworks, los cuáles brindan funcionalidades comunes a toda aplicación. También incluyen generadores de código fuente, que construyen automáticamente elementos de uso común en base a características específicas. Ejemplo de ello es el Generador de Formularios del Framework para PHP llamado Symfony, que genera formularios web a partir de la definición del modelo de una base de datos.
¿Generadores de código fuente?
En este momento podría surgir la duda de por qué usar un generador de
código fuente, si estos podrían generar código repetitivo. Si bien esto
es cierto, no se salen del principio de DRY, ya que en realidad el
código fuente generado automáticamente ha sido construido a partir de un
mismo origen: el generador de código fuente. Esto implica que si se
hace uso del mismo generador, este construirá el mismo código fuente en
cualquier momento si se proporcionan las mismas condiciones para su
generación.
Observaciones finales
El principio DRY nos presenta facilidades y ventajas con respecto a
WET, ya que a la larga pueden facilitarnos el trabajo al reducir el
tiempo de programación reutilizando elementos y funcionalidades ya
existentes. Sin embargo, el llevar un sistema a una estructura DRY puede
llevar tiempo de análisis, y muchas veces no será perfecto. Pero a
pesar de esta desventaja, considero que vale la pena hacer el intento,
ya que a la larga nos facilitará el trabajo a nosotros mismos quienes
desarrollamos una aplicación, así como a los colegas que se encargarán
de extender nuestro sistema informático en un futuro.
Los invito a escribir sus comentarios y opiniones acerca de este tema.
Publicado originalmente el 16/08/2012, en http://itsouvenirs.wordpress.com/2012/08/16/consejos-de-programacion-1-dont-be-wet-stay-dry/.
0 comentarios:
Publicar un comentario