Manuel Zapata
Como desarrolladores de software, a veces nos gusta anticiparnos a futuras necesidades de nuestras aplicaciones. El reto es que podemos terminar creando trabajo adicional para nosotros, que no está basado en requerimientos reales de nuestros usuarios.
Es aquí donde entra el principio YAGNI, para ayudar a enfocarnos en lo que realmente importa. Te dejo un vídeo sobre el tema, que hace parte de la serie Programador Senior de mi canal de YouTube.
Si prefieres leer, debajo del video te dejo una versión escrita del principio YAGNI.
Link al vídeo de YouTube | Suscríbete a mi canal
¿Qué es el principio YAGNI?
Sí, es una nueva sigla. En este mundo de la informática nos encantan las siglas.
En este caso, YAGNI significa: You Aren´t Going to Need It. Es decir, No lo vas a necesitar.
Al igual que el principio KISS, lo que buscamos aquí también es simplificar, pero simplificamos eliminando código o funcionalidades que la aplicación no necesita.
Esta idea viene de la programación extrema (XP), es decir, viene del mundo de las metodologías ágiles. En esta Ron Jeffries decía lo siguiente:
Siempre implementa algo cuando REALMENTE lo necesites, no cuando se te acaba de ocurrir que potencialmente lo vas a utilizar.
La idea es no tratar de implementar cosas porque tú crees que a lo mejor van a suceder, o que la aplicación va a necesitar. La idea es que las implementes cuando sepas que realmente las necesitas.
Ejemplos que te indican que necesitas la funcionalidad:
- Un usuario te la está pidiendo,
- Una nueva tendencia en el mercado la está requiriendo
- Un requerimiento legal la hace obligatoria.
La idea es no anticipar ese tipo de funcionalidades que no tienes certeza de si van a ser requeridas o no. Evitar una ingeniería excesiva del sistema sin ninguna necesidad.
¿Qué podría ocurrir si ignoras el principio YAGNI?
Si diseñas y desarrollas algo partiendo del supuesto de que lo podrías llegar a necesitar, pueden ocurrir dos cosas:
- La funcionalidad realmente no se necesitaba,
- O la idea original que tenías va a cambiar, y entonces vas a desperdiciar ese trabajo.
Vas a invertir un tiempo que a lo mejor tu equipo pudo aprovechar desarrollando otras funcionalidades que sí eran necesarias. Además de eso, vas a introducir algo nuevo en el sistema que vas a tener que mantener.
Lo anterior implica que vas a modificar otras partes que ya existen. Vas a generar nuevos errores, y tendrás que empezar a arrastrar con el mantenimiento de eso que introdujiste, solamente porque tenías el presentimiento de que lo ibas a necesitar.
Ojo aquí. YAGNI aplica a posibles funcionalidades.
No tiene nada que ver con el código que hace que el sistema sea fácil de modificar y mantener. La tendencia común es pensar en hacer solo las cosas que se necesiten, y que entonces hay que tomar atajos en la arquitectura. Que vamos a empezar a utilizar la programación orientada al machete, y nos olvidaremos de las buenas prácticas.
Esa no es la idea.
Analízalo cuidadosamente. El hecho de que decidas seguir el principio YAGNI, significa que con mayor razón, tu sistema tiene que ser mantenible y fácil de modificar. La razón es sencilla. Es como si estuvieras diciendo: “Oiga, hoy no voy a hacer esa funcionalidad. Voy a esperar al momento en que la necesite”.
¿Eso qué implica?
Implica qué vas tener que modificar el sistema después.
Por ende, tienes que asegurarte hoy que los cambios que vas a introducir en un futuro, sean viables y fáciles de hacer.
Es muy importante tener en cuenta los conceptos de arquitectura y de diseño de los que hemos hablado. Esto, para lograr que el principio YAGNI sea exitoso, y lo puedas implementar de la forma correcta.
¿Cuál es el mayor reto del principio YAGNI?
El reto es detectar cuál es el momento ideal para hacer algunos cambios.
Lo que nos enseñan las estadísticas y la literatura sobre la gestión del cambio, es que hay ciertos tipos de cambios en el sistema, que entre más pronto se introduzcan, va a ser mucho más barato y fácil hacerlos.
Esto nos lleva a preguntas como:
- ¿Cuál es el momento ideal para introducir un cambio?
- ¿Debería introducirlo exactamente cuando se necesita?
- O para ciertas funcionalidades, ¿debería introducirlo antes?
Un ejemplo de esto es cuando quieres implementar localización en una aplicación.
Tú dices: “Bueno, en este momento solo tengo que soportar un idioma. De pronto se pueden necesitar otros, pero no es seguro”. Podrías decidir implementar la localización cuando te pidan un segundo idioma en la aplicación.
Sin embargo allí hay un problema. Vas a tener una gran cantidad de texto disperso por distintas páginas de la aplicación. Esto implicaría modificar muchas partes del código, y el riesgo de hacer esto sería muy alto.
Si desde el inicio del proyecto decides que las vistas van a soportar localización, así sea solo un idioma el que se requiera, ya te ahorraste todos los cambios y el esfuerzo de implementar un segundo idioma después.
Aunque el escenario anterior es un poco diferente, ya que es una decisión de arquitectura, explica bien el asunto. Desde el punto de vista de la gestión de cambios, entre más pronto se tome una decisión, mejor.
La experiencia te va a ir dando la habilidad de saber cuál es el punto ideal para introducir ciertos tipos de cambios. Lo importante es que siembres la semilla, que facilite hacer los cambios en un futuro, cuando se requieran
Cierre
En general es una buena idea seguir el principio YAGNI, especialmente en negocios donde todo se va moviendo muy rápido. Es muy importante que seas capaz de ir pivoteando e ir cambiando de acuerdo a las necesidades del mercado, y no tomar decisiones tempranas, talladas en piedra, que van a salir muy costosas después.
Espero que te haya quedado claro el principio YAGNI. Tenlo en cuenta cuando estés tomando decisiones sobre funcionalidades.
Este principio y muchos otros más, te ayudarán a formarte para ser un programador senior.
Para cerrar te recomiendo mi minicurso gratuito de principios de diseño.
Estudiamos los principios SOLID para que puedas desarrollar mejores aplicaciones.
Espero que te haya gustado.
