yagni diseño simple

YAGNI: En software, mejor el diseño simple


En un entorno ágil en el que no nos adelantamos a los acontecimientos y hacemos solo lo que es más prioritario y aporta valor, la excelencia técnica y el diseño simple es fundamental. Necesitamos poder absorber cambios rápida y fácilmente. Por eso los desarrolladores ágiles lo tienen claro. Si no lo vas a necesitar (YAGNI) no pienso construirlo.

De dónde sale tanta complejidad

“Haz todo tan simple como sea posible, pero no más simple”, Albert Einstein

Esta frase tan conocida, no es para nada lo que se practica en el mundo del software. No sé si es porque los desarrolladores de software se caracterizan por una capacidad superior de abstracción. Quizás sea por un afán de predecir el futuro y preparar el sistema para cualquier posible nueva funcionalidad futura que pueda existir. Los desarrolladores tendemos a hacer más complejo el software de lo que realmente es necesario.

Uno de los fundamentos de diseño de software es el dejar el sistema preparado para su extensión. Un desarrollador tiene eso en la cabeza. El impulso de todo programador es dejar el sistema lo más genérico posible para que si en el futuro surge una nueva necesidad sea posible añadirla con el menor esfuerzo. El hacer el producto genérico aumenta la complejidad de éste.

Lo que era una ventaja se convierte rápidamente en un inconveniente. El aumento de la complejidad deriva en que el código es más difícil de leer, de entender y de modificar, en definitiva se dificulta la extensión, es un pez que se muerde la cola. Y no acaba aquí, como consecuencia mata la productividad y la moral de los equipos de desarrollo, pues cualquier pequeño cambio en el sistema es una odisea.

En las metodologías tradicionales, la complejidad añadida comienza en la definición del producto. En la toma de requerimientos, el cliente debe definir por adelantado todo lo que el sistema tendrá que hacer y satisfacer. Esto obliga a que quién hace esta definición a pedir toda una serie de funcionalidad “por si acaso”, a dotar el software de cosas que después probablemente no se usarán, ya que más tarde en el desarrollo no tendrá más oportunidades de incorporarlo. El sistema está viciado desde el principio, desde su definición.

yagni software simple

Hay una alternativa: YAGNI

Lean ya habla de desperdicio en todo lo que no se ha pedido. Otros principios que posteriormente se han popularizado (KISS, Resume Driven Development, Gold Plating) en esencia lo que dicen es lo mismo. Esto de hacer por hacer es una mala idea.

La aproximación de eXtreme Programming (XP) es bastante clara y radical con el tema. El primero de sus valores es la simplicidad. Literalmente, el equipo se centrará en hacer un trabajo excelente en las características que se necesitan para el momento actual, sin intentar adivinar nada de lo que vendrá más tarde. Esta es, según esta metodología, la mejor manera de aumentar el valor para el cliente.

El principio YAGNI de XP apunta directamente al problema. Si solo se usa una pequeña parte de la funcionalidad extra estás malgastando el tiempo tontamente. Debemos concentrarnos en lo que se necesita hoy. Si nuestro diseño es simple, si mañana necesitamos esa funcionalidad extra será fácil añadirla, más que si tenemos un sistema cargado de complejidad.

En XP se usa TDD, esto es, hacer los tests antes de hacer el código. La regla es simple, no se puede escribir nada de código hasta que no veas un test fallar. Aunque pueda parecer absurdo, es un camino seguro para no hacer nada extra. Es en esencia pensar antes de hacer las cosas. Cuando escribes el test estás especificando un caso particular para un requerimiento. Un ejemplo vaya. Una vez tienes el ejemplo, hacer que el software funcione con el ejemplo. Si no hay más ejemplos que satisfacer no merece la pena seguir inventando funcionalidad.

Otra técnica esencial que se utiliza en paralelo a TDD es la refactorización. Se trata en esencia de modificar la estructura del código sin que cambie su comportamiento. Esta práctica es esencial en el desarrollo iterativo, ya que no tenemos claro un esquema de clases desde un inicio, hay que ir limpiando y puliendo lo que construimos. Con la refactorización identificamos el código repetido y enrevesado, y lo sustituimos por una mejor estructura. Esto se consigue haciendo emerger los principios y patrones de diseño donde se necesitan realmente, no donde prevemos que se van a necesitar en el futuro.

No prever el futuro no significa no analizar

Que nadie me malinterprete. No he querido decir que no se tenga que hacer análisis y diseño antes de comenzar a desarrollar. Lo que se propone es que éste análisis no intente adivinar el futuro y que sea mínimo, es decir, que analicemos hasta el punto en el que ese análisis aporte valor.

También que no nos dé miedo afrontar el cambio durante el proceso de desarrollo. Si el software es complejo y no está soportado por unos buenos tests, es complicado absorber muchos cambios. Pero si el software construido sigue el diseño simple, está bien refactorizado y tiene una buena cobertura de tests unitarios y de integración, será sencillo después acomodar cambios de requerimientos y de opinión en el desarrollo.

También te puede interesar...

Los 7 desperdicios LEAN del software (y II) Este post es la continuación al post anterior Los 7 desperdicios del desarrollo de software donde describía los primeros 3 desperdicios del desarrollo...
Resumen Lean Software Development El libro Lean Software Development de Mary y Tom Poppendieck es una lectura obligatoria para todos aquellos que quieran entender muchos de los princip...
Taller de Kanban Pizza Kanban es mucho más que un tablero bonito con PostIts. Hay toda una filosofía detrás que casa muy bien con los principios ágiles (algunos son calcados...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *