Menos es más. Filosofía detrás de los principios YAGNI, KISS, DRY, DIE, hijos de la navaja de Ockham.

0
7203

Menos es más. Filosofía detrás de los principios YAGNI, KISS, DRY, DIE, hijos de la navaja de Ockham.

Índice de contenidos.

Introducción

Este artículo pretende profundizar en el significado de todas las frases bonitas que utilizamos hoy en día y que quedan tan bien en las charlas de ponentes en ferias tecnológicas.
Ahora que programar está a la moda, mucha gente influyente ha acuñado términos sencillos y directos con un acrónimo del que es fácil acordarse, como DRY «seco», KISS «beso» o DIE «morir».

Quizá KISS (Keep It Simple, Stupid!) es el mejor ejemplo de lo que estoy diciendo.

Esto busca viralizar la frase, lo cual no es malo, ya que el mensaje de fondo es algo que todos deberíamos aplicar en nuestro día a día como programadores, e incluso en nuestra vida diaria.

Orígenes, la navaja de Ockham

Todo comienza con William de Ockham, un fraile franciscano que vivió entre el 1287 y el 1347. Propuso que cuando había que elegir entre varias hipótesis, lo mejor era considerar como cierta la que menos asunciones hiciera siempre que el resto de parámetros se mantuvieran constantes.

«All things being equal, the simplest solution tends to be the best one»

«Mientras todo se mantenga igual, la solución más simple tiende a ser la mejor»

Como curiosidad, el término Navaja de Ockham apareció siglos mas tarde, acuñado por Sir William Hamilton en 1852.

Mucha gente puede intentar radicalizar esto, siendo demasiado simplistas, podemos decir que todo es obra de la magia.

Para evitar estas evidentes falacias, me gustaría acotar el principio de Ockham con una frase acuñada por Albert Einstein

«Everything Should Be Made as Simple as Possible, But Not Simpler»

«Todo debería ser tan simple como sea posible, pero nunca mas simple que eso»

Keep It Simple, Stupid!

Aunque se ha traducido normalmente por Keep it simple, stupid! (¡manténlo simple, idiota!), esto es simplemente por dar mas juego al acrónimo, ya que su autor, Kelly Johnson lo ha traducido sin coma, lo que no insulta al ingeniero encargado si no que refuerza la idea de sencillez.

Esta frase goza de mucha popularidad entre los conferenciantes y evangelistas de las buenas prácticas porque, como se puede apreciar, es una frase con mucha fuerza, que hace despertar a los oyentes y les insta a twittear y difundir el mensaje (y al mensajero).

Todo lo que sea mejorar la calidad de nuestros programas lleva a una mejor y más barata mantenibilidad, y por lo tanto estoy a favor 🙂

You Aren’t Gonna Need It

Literalmente traducido por «No vas a necesitarlo». Este principio esta detrás de otro mucho mas largo y feo como es DTSTTCPW utilizado en extreme programming que viene a decir «haz la cosa mas simple que pueda funcionar» (Do The Simplest Thing That Could Possibly Work).

Está pensado para utilizarse en la metodología de trabajo de extreme programming junto con las pruebas y la refactorización. Ayuda a no intentar hacer una mega-solución que solucione los problemas del mañana porque estos pueden cambiar, y, en lugar de esto, centrarse en únicamente lo necesario, que por otra parte es por lo que nos pagan.

Don’t Repeat Yourself (DRY) / Duplication Is Evil (DIE)

Agrupo estos dos acrónimos porque su significado es el mismo, «no te repitas» y la «duplicación es el mal».

Si ya tienes una funcionalidad existente, es mejor reutilizarla que duplicarla, porque en este caso tendrías que mantener ambos algoritmos. Esto suena demasiado sencillo (y lo es), pero el mayor problema que he observado, en el que se escuda la gente, para no duplicar código es que dos funcionalidades no suelen ser exactamente iguales, siempre hay sutiles diferencias que hacen que sea mas fácil copiar lo que tenemos y pegarlo con pequeñas modificaciones.

El «truco» para evitar esto es la refactorización. Extraer las partes comunes es esencial para no duplicar funcionalidad, es una de las partes fundamentales del TDD y del extreme programming.

Si has seguido el principio YAGNI probablemente tengas código duplicado con otras funcionalidades parecidas pero no iguales.

Para aplicar además los principios DRY y DIE, ahora es el turno de refactorizar extrayendo partes comunes para eliminar duplicidad en tu código.

Una vez hecho esto consigues contentar a todos los principios y puedes empezar con la siguiente funcionalidad.

Conclusiones

Podríamos decir que hemos «refactorizado» estos principios para extraer la parte común de ellos, sería curiosa la reacción de la gente que los propuso ver que se a aplicado su principio a si mismo 😉

Espero que con este artículo ahora poseáis una vision común de todo esto y que tengáis un criterio propio para defender su uso frente a otros trabajadores que prefieren mirar a corto plazo y copiar/pegar trocitos para sobrellevar el día a día o crear una super arquitectura que pueda resolver cualquier posible cambio que se produzca de aquí a años vista (porque probablemente eso no pase).

Como siempre os digo, utilizad el sentido común, nada es blanco o negro. Espero que os haya gustado y haberos aclarado dudas que pudierais tener.

Samuel Martín.

Dejar respuesta

Please enter your comment!
Please enter your name here