En este tutorial vamos a hablar sobre el principio YAGNI (You Aren’t Gonna Need It) de la metodología Extreme Programming (XP).
0. Índice de contenidos
- 1. Introducción
- 2. YAGNI, las cosas claras
- 3. Motivación y explicación
- 4. Cuándo usar YAGNI
- 5. Conclusiones
- 6. Referencias
1. Introducción
¿Quién (dentro del mundillo del desarrollo software) no se ha encontrado nunca con el siguiente caso?
Te encuentras desarrollando una aplicación (ya sea para un cliente, para tu empresa, o para ti mismo), y empiezas a añadir funcionalidades de cara al futuro. No sabes si realmente se va a usar, pero bueno, si alguna vez se necesita, ahí estará…
El tiempo pasa, la aplicación crece y sigues sin utilizar esa funcionalidad. Entonces, ¿para qué se desarrolló? ¿Habrás perdido el tiempo?
Respuesta corta: SI.
Respuesta larga: No, pero no parece que se vaya a utilizar de momento, así que… SI.
El principio YAGNI trata este escenario de manera tajante.
2. YAGNI, las cosas claras
¿Qué nos dice el principio YAGNI?
Fácil: «You aren’t gonna need it», es decir, no vas a necesitarlo.
Esto quiere decir que sólo se desarrolle lo que se vaya a usar en el momento, que se piense si se va a usar la funcionalidad y si se va a necesitar en un futuro inmediato. No se debe desarrollar algo que no se vaya a usar «pronto», aunque se sepa con certeza que se va a tener que implementar en un futuro.
Resumiendo: No se implementa en el momento, se implementa cuando se necesita.
¿Cuáles son las ventajas de este principio?
- Se ahorra tiempo de desarrollo: no se destina a funcionalidad «no útil».
- No se pierde tiempo de prueba ni de documentación asociado a la funcionalidad no necesaria.
- Se evita pensar en las restricciones de la funcionalidad no necesaria: no se cierra el proyecto en función de la funcionalidad no necesaria.
- El código no crece más de lo necesario, y no se complica.
- Evita que se añada más funcionalidad similar a la que no se va a usar.
3. Motivación y explicación
¿Por qué surgió YAGNI? Es decir, ¿por qué los programadores tienden a desarrollar características que no se necesitan?
Implementar una funcionalidad similar a otra que se acaba de desarrollar es más fácil que algo completamente diferente. Si se desarrollan dos características similares una tras otra se sabe mejor como desarrollar la segunda (porque se ha hecho algo similar antes). Esto es más fácil que desarrollar la primera, luego hacer algo distinto y finalmente desarrollar la segunda.
El problema surge porque:
- Muchas veces una funcionalidad no será usada.
- Aunque se vaya a usar una funcionalidad, hay alta probabilidad de que cambie, ya que se necesita algo diferente a lo que se ha desarrollado.
- La nueva funcionalidad sí que se usa y del modo que se ha diseñado, pero no se saca beneficio de ella.
Si estamos en el primer caso, el tiempo dedicado a desarrollarla se ha perdido. No importa si se ha «financiado». Si la ha financiado la empresa el tiempo se ha perdido igualmente. Si la han desarrollado programadores junior fuera de horario de trabajo con la excusa de «aprender», han hecho trabajo gratis y han perdido el tiempo (podían haber aprendido otras cosas que sí reporten algo).
Si la característica sí que se necesita, pero no es exactamente lo que se necesita, hay que modificarla para que se adapte (segundo caso). Esto implica que el tiempo dedicado a realizarla no se ha perdido del todo, pero hay que gastar más tiempo en modificarla; tiempo que se ahorraría si se hubiera esperado a realizarla en el momento adecuado, sabiendo el comportamiento final.
Aunque se haya desarrollado una funcionalidad necesaria y de forma correcta, si no reporta beneficio alguno, los costes asociados a su desarrollo prematuro no se cubren, ya que se ha incrementado la complejidad de probar y mantener el código, y puede que haya provocado un retraso en otras funcionalidad necesarias anteriormente.
4. Cuándo usar YAGNI
El caso en el que parece que se saca más partido a este principio es cuando se está desarrollando una funcionalidad que será necesitada por otra, y se necesita funcionalidad adicional, pero que será inútil cuando la segunda esté finalizada. Vamos a explicarlo de un modo más simple con un ejemplo.
Supongamos que se necesita una funcionalidad (Funcionalidad_1) y que la necesitamos tener sin estar desarrollada otra funcionalidad (Funcionalidad_2). Como Funcionalidad_1 necesita código auxiliar lo creamos, sabiendo que cuando Funcionalidad_2 esté terminada, esta funcionalidad auxiliar será inútil y habrá que desecharla.
Podemos pensar que desarrollar funcionalidad que se vaya a «tirar» es un mal olor del software. Entonces decidimos que hay que modificar la funcionalidad auxiliar para que cuando Funcionalidad_2 esté finalizada se pueda utilizar en ella también, pero…
¿No es eso lo que YAGNI quería evitar?
No, no lo es. YAGNI dice que no se implemente una funcionalidad que no sea necesaria, no que no se implemente una funcionalidad necesaria en un momento aunque luego se descarte. ¿Se ve la diferencia?
Pero aplicar este principio no siempre da buenos resultados. En estos casos ocurre que hay que realizar un cambio muy costoso que si se hubiera hecho en una etapa anterior hubiera sido más fácil de «arreglar». Sin embargo, estas situaciones son raras y sus costes son despreciables si los comparamos con los éxitos de aplicar YAGNI.
Para finalizar, ahí va una lista «resumen» de YAGNI:
- Crear código extra necesario para una funcionalidad NO es YAGNI.
- Crear una funcionalidad que no se va a usar SI es YAGNI.
- Refactorizar NO es YAGNI.
5. Conclusiones
YAGNI sólo se aplica a las funcionalidades que se crean para dar soporte a una funcionalidad que no se sabe si se usará, no al esfuerzo necesario para hacer que el código sea más fácil de modificar.
De esta forma, se ve claramente que este principio es una estrategia viable siempre que se introduzca más complejidad en el código y no se vaya a aprovechar hasta más tarde. Sin embargo, si se crea código para alguna funcionalidad futura y éste no añade complejidad al código, no es necesario «invocar» YAGNI.
En estos párrafos se ha introducido un principio que ayuda a desarrollar software de manera rápida (junto con los demás principios que ya conocemos y que nos quedan por conocer). Hemos visto también que YAGNI no es sólo lo que dice la frase que lo define, si no que va más allá y entra en un terreno más «filosófico» por llamarlo de alguna manera. Para terminar, se ha visto que un fallo aplicando YAGNI es pequeño comparado con un éxito en la invocación del principio.
Espero no haberos aburrido demasiado. ¡Un saludo!
Rodrigo de Blas
6. Referencias
- Yagni. Martin Fowler.
- Some thoughts about yagni. Peter Verhas.
- You aren’t gonna need it. Wikipedia