Saltar al contenido principal

Introducción a las cualidades de diseño

Este artículo es una adaptación de Cualidades de diseño, elaborado por Nicolás Passerini, Carlos Lombardi, Fernando Dodino, Leonardo Gassman, Rodrigo Merino, Juan Zaffaroni, Franco Bulgarelli y Federico Aloi.

Cuando nos toca analizar un sistema, ya sea existente o aún tan sólo presente en nuestras mentes, frecuentemente nos encontraremos con aspectos de su diseño que “nos hacen ruido”: por ejemplo, muchas veces veremos partes difíciles de modificar, o excesivamente complejas, o que presentan abstracciones confusas.

Y si somos además responsables del uso, mantenimiento o construcción de dichos componentes, probablemente esto venga acompañado del recuerdo poco feliz de las personas que lo idearon. 😅

¿Qué son las cualidades de diseño?#

Esto nos da una intuición sobre qué es la calidad del diseño. Lo que buscaremos ahora es justamente refinar esta idea, formar criterios más sofisticados sobre qué diferencia a un buen diseño de uno deficitario, que conoceremos como cualidades de diseño. Puesto en otros términos, nos ayudará a poder responder la pregunta: ¿es el diseño A mejor que B?

Lo interesante es que estos criterios nos permitirán analizar y tomar decisiones más formadas. No serán nuestras únicas guías, claro: el criterio, experiencia y conocimiento de quienes construyan el software serán elementos clave. Por lo tanto, debemos interpretar las cualidades de diseño como heurísticas antes que reglas.

Las cualidades de diseño, como veremos a continuación, estarán en general enunciadas en forma de principios más o menos genéricos, pero cuya interpretación será diferente según la tecnología empleada. Por ejemplo, analizar el acoplamiento entre dos componentes desarrollados bajo el paradigma funcional será diferente de hacerlo entre dos componentes desarrollados bajo el paradigma de objetos.

¿Para qué sirven las cualidades de diseño?#

Como adelantamos, las cualidades de diseño nos servirán para comparar diseños y tomar decisiones sobre ellos. Por un lado, expandirán nuestra mente y nos recordarán varios aspectos a tener en cuenta antes de tomar una decisión de diseño. Y por otro lado nos darán un vocabulario más rico que nos permitirá justificar mejor nuestras opiniones y decisiones.

Para hablar de cualidades de diseño, deberemos tener siempre un diseño alternativo en mente. No podemos decir que una pieza de software es simple o es robusta, sino que es más simple o más robusta que otra que resuelva la misma problemática. Y en general también deberemos tener en cuenta un contexto: por ejemplo, un diseño para un componente no es más flexible que otro en términos absolutos, sino más flexible ante un cierto escenario de cambio.

Tensiones entre las cualidades#

Como veremos más adelante, muchas veces nos encontramos con que favorecer una cualidad de diseño en una solución perjudica a otra. O por el contrario, una mejora en una se traduce también en una mejora en otra. Es decir, algunas cualidades tienen correlación positiva, como por ejemplo cohesión y abstracción, o desacoplamiento y testeabilidad. Pero otras entran en conflicto y más bien, parecen oponerse: flexibilidad y robustez o simplicidad y extensibilidad.

Es el síndrome de la frazada corta: o me abrigo los pies o me abrigo los hombros, pero ambas cosas no puedo. 🤷

Estos casos son más interesantes, porque tenemos que elegir a qué cualidad le daremos preponderancia. Y no sólo con conocimiento técnico sino también con conocimiento del negocio y del contexto humano del desarrollo.

Algunos ejemplos:

  • Si estamos construyendo un sistema provisorio cuyo tiempo de vida estimado es de 6 meses, no necesito pensar en la mantenibilidad.
  • Si estoy construyendo un prototipo para validar la idea de un producto o servicio, la simplicidad será clave.
  • Si soy responsable de un sistema de control de un avión que por diseño no va a cambiar, la flexibilidad no me parecerá importante pero la performance y robustez serán críticas.
  • Si estoy desarrollando un sistema para una clienta, pero sé que en el futuro inmediato tendré que construir sistemas muy similares para otros clientes, probablemente valga la pena construir buenas abstracciones genéricas que me permitan reutilizar los componentes.

Apéndice: un ejemplo real#

A modo de ejemplo, les presentamos la documentación del API de tiempo (en inglés 🇺🇸) introducida en la versión 1.8 del Java Development Kit (JDK). Es interesante que quienes desarrollaron la misma se tomaron su tiempo para explicarnos no sólo qué hacen sus componentes sino las decisiones de diseño que tomaron al implementarlo.