El principio YAGNI en el desarrollo de software: ¿Realmente necesita esa abstracción o código genérico?

¿Qué es YAGNI? No construya lo que no va a necesitar

En el centro de este debate está el principio YAGNI, que significa You Aren't Gonna Need It (No lo vas a necesitar), un concepto clave de la programación extrema y el desarrollo ajustado de software. Como explica Derek, YAGNI dice a los desarrolladores que no implementen características o funcionalidades que creen que necesitarán en el futuro, sino que se centren en los requisitos actuales.

Derek añade un matiz: aunque hay que evitar escribir código especulativo, tampoco hay que atarse las manos para no poder adaptarse más tarde. El reto consiste en evitar dedicar tiempo a características que podrían ser útiles y, al mismo tiempo, estar abierto a cambios. Se trata de un dilema habitual en el software ágil y la ingeniería de software.

Describe dos aplicaciones erróneas habituales de YAGNI:

1. Planificación de características - Usted se anticipa a los requisitos futuros y empieza a construir ahora.

2. Abstracciones de código - Se generaliza o abstrae el código existente demasiado pronto, adivinando otras características que podrían ser necesarias.

En ambos casos, el resultado suele ser un esfuerzo inútil, una complejidad añadida y una proliferación de funciones, justo lo contrario de lo que promueven las buenas prácticas y el principio KISS (Keep It Simple, Stupid).

Un ejemplo real: Sistema de notificación de envíos

Para ilustrarlo, Derek utiliza el ejemplo de un sistema de gestión de envíos que envía un SMS a un usuario una vez entregado su paquete. El sistema utiliza Twilio, y la función funciona gestionando un evento de entrega, obteniendo información de contacto y enviando un mensaje.

Este sencillo proceso de desarrollo de código aborda el requisito actual. Debe ser sencilla, comprobable y aportar valor. Pero entonces, surge la pregunta: ¿Y si en el futuro queremos cambiar de proveedor de SMS?

Aquí es donde muchos desarrolladores invocan incorrectamente el principio YAGNI. Asumen que, dado que otra implementación podría llegar más adelante, necesitan abstraer la lógica del SMS ahora. Así que crean una interfaz como ISmsService.

Abstracciones: ¿Estás construyendo para un futuro que puede que no exista?

Derek cuestiona esta abstracción temprana: si sólo se dispone de una implementación y no existe la necesidad actual de cambiar de proveedor, ¿para qué abstraer? Estás añadiendo una complejidad innecesaria para hacer la vida más fácil en una necesidad futura que puede que nunca se materialice.

Además, ilustra el coste de la ingeniería de software. Cuando acabas añadiendo un segundo proveedor, te das cuenta de que tu interfaz está demasiado acoplada a las necesidades específicas de Twilio (como su lógica de número de teléfono "de"). De repente, la abstracción se convierte en un lastre. Así es como las abstracciones basadas en conocimientos limitados suelen introducir errores y complicar la refactorización.

La clave: no se ahorra tiempo, sino que se construye algo mal debido a un contexto insuficiente.

Volverse genérico demasiado pronto: Una trampa para desarrolladores

Una de las infracciones más comunes de YAGNI en los proyectos informáticos es el empeño en hacer las cosas genéricas antes de que sea necesario. Derek lo explica con otro ejemplo: la agrupación de notificaciones por SMS y correo electrónico en un único sistema de notificación genérico.

Para ello, un desarrollador podría definir un NotificationType (SMS o Email), un campo de dirección universal y crear un único servicio que gestione ambos. Pero este diseño excesivamente abstracto acaba complicando la lógica y creando rutas de código condicional frágiles y difíciles de mantener.

Se trata del clásico "feature creep", un sello distintivo de ignorar el desarrollo ajustado de software y los principios sólidos. Estás escribiendo código especulativo que no responde a ninguna necesidad inmediata del usuario, una señal de alarma en cualquier proceso ágil de desarrollo de software.

Prefiera la extensión a la modificación

En lugar de un exceso de ingeniería, Derek sugiere el enfoque de solución más sencilla: si más adelante necesitas admitir notificaciones por correo electrónico, simplemente implementa esa función por separado.

Al utilizar una arquitectura basada en eventos, cada evento puede desencadenar múltiples gestores independientes. Por ejemplo, un gestor para SMS y otro para correo electrónico. Más adelante se podrá eliminar una sin que afecte a la otra. Este método promueve la simplicidad, admite requisitos cambiantes y respeta la separación de preocupaciones, todo ello en consonancia con las mejores prácticas de desarrollo ágil e impulsado por pruebas.

Al construir sistemas extensibles, no sobrediseñados, se mantiene la flexibilidad sin predecir todos los futuros posibles. Así se evita la complejidad innecesaria y se mantiene la adaptabilidad.

El coste real de violar la ley YAGNI

Derek destaca el coste real de crear funciones innecesarias:

• Tiempo invertido en construir algo que nunca se usa

• Complejidad añadida que no aporta valor inmediato

• Aumento del coste de propiedad para los desarrolladores que ahora tienen que mantener código no utilizado o sobrecargado

• Más espacio para bugs y errores por exceso de ingeniería

Esto concuerda con otro principio básico del desarrollo ágil de software: centrarse en ofrecer valor ahora, no posiblemente más tarde.

Señala que los desarrolladores experimentados a menudo cometen el error de confiar en sus instintos sobre las necesidades futuras, y se equivocan. Incluso con experiencia, predecir lo que su sistema necesitará dentro de unos meses suele ser un juego perdido.

Pensamientos finales: El contexto importa, la simplicidad gana

Derek concluye aclarando que no está en contra de los principios de diseño ni de las abstracciones. De hecho, cree en la construcción de sistemas que puedan evolucionar. Pero el error está en implementar cosas sin justificación actual, es decir, violando YAGNI.

Anima a los desarrolladores a "escribir código e implementar funciones que tengan valor ahora" Evite perseguir requisitos futuros a expensas de sus usuarios actuales. Cíñase a las prácticas de código limpio y favorezca las estrategias de diseño que admitan cambios sin encerrarle en estructuras especulativas.

También invita a los desarrolladores a compartir sus propias historias de terror con YAGNI, en las que construyeron para el futuro y nunca lo necesitaron, una historia común en muchos proyectos.

Conclusión: Aplique YAGNI a su proceso de desarrollo

El principio YAGNI sigue siendo una de las herramientas más valiosas en la caja de herramientas de un desarrollador. Está en consonancia con las filosofías ágil, lean y KISS, que nos recuerdan que debemos construir solo lo necesario, nada más. El desglose que hace Derek Comartin de esta idea en su vídeo, a través de ejemplos de código y procesos de desarrollo del mundo real, ofrece una orientación clara sobre cómo aplicar YAGNI con eficacia.

Así que la próxima vez que te sientas tentado a añadir una capa de abstracción, una clase genérica o una función adicional, haz una pausa y pregúntate:

¿Estás resolviendo un problema que tienes -o uno que sólo supones que podría aparecer algún día?

Evite perder tiempo en futuros imaginarios. Céntrese en crear valor hoy mismo. El software debe ser sencillo, fácil de mantener y responder a las necesidades reales.

Porque lo más probable es que no las necesites.