miércoles, 17 de septiembre de 2014

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/.

Related Articles

Con la tecnología de Blogger.