Seleccionar página
Introducción a desarrollo guiado por especificación TDD

Introducción a desarrollo guiado por especificación TDD

Por | Dic 31, 2020 | Agilidad | comentarios

En realidad TDD significa Desarrollo guiado por pruebas, del inglés Test Driven Development. Lamentablemente es un nombre que no le hace justicia, lo que realmente guía al desarrollo siguiendo esta práctica, son las especificaciones o comportamientos.

Ya sé, ya sé, para la gente que sabe que es BDD seguro se pregunta, ¿Guiado por comportamiento?, ¿Eso no es BDD?, pero el contenido de esta publicación clarificará la estrecha relación entre TDD y BDD. Mostraremos una perspectiva en la que en esencia, son lo mismo.

Origen de TDD en la vida

Una de las características principales y de hecho el primer paso cuando se aplica desarrollo guiado por pruebas es el entender bien el problema a resolver. Es por eso que se escriben las pruebas primero, esta idea ha existido desde que el ser humano hace cualquier tipo de trabajo, ejemplo:

Un cazador enseña a su hijo como cazar una cebra y le indica que el mejor lugar para clavarla es justo debajo de la oreja, donde puede atravesar su cráneo, pero ese es un tiro muy difícil. Le dice que el tiro más facil es “Apuntar a las rayas que la cebra tiene en el pecho”. Mientras el padre dibuja las rayas en el tronco de un árbol (simplicidad).

– Sigue practicando el tiro a una distancia de 20 pasos hasta que claves la lanza correctamente”, luego -“No espera, sostén la lanza así”, más tarde – “Si, así está mejor, continua así” … – “Ahora, pídele a tu tío que te enseñe cómo hacer que la cebra se acerque a una distancia de 10 pasos” (iterativo e incremental, lotes pequeños, ciclo de retroalimentacion)

Bob Allen de codecraftsmansaturdays

El objetivo del padre y del hijo es que este último pueda cazar una cebra (enfoque). 

Lo ideal es clavar la cebra justo debajo de su oreja. Esto es una tarea difícil para el hijo, entonces utilizando un proceso iterativo e incremental, se empieza con el paso más fácil hasta ahora conocido. El paso es apuntar al pecho de la cebra a una distancia de 20 pasos (simplicidad).

Después surge otro inconveniente, sostener la lanza correctamente, por eso se trabaja en ello. Posteriormente surge otra cosa, hacer que la cebra se acerque hasta 10 pasos de distancia (lotes pequeños, iteraciones y vamos incrementando hasta la meta). Aunque no se menciona la razón, podemos suponer que, el padre se quiere asegurar que el hijo pueda clavar la cebra en el primer tiro

Ahora bien, de momento se cumple el objetivo (enfoque), cazar a una cebra, por lo que el padre y el hijo pueden detenerse ahí. Conforme se empieza a trabajar en la solución, muchas veces esta es mucho más simple de lo que se pensaba en el inicio.

El punto es que este proceso iterativo e incremental permite ahorrarnos tiempo, dinero y esfuerzo implementando una solución mucho más simple. Y si te preguntas cuál es la solución complicada, esa es la de “clavarla justo debajo de la oreja”.

TDD está basado en principios ágiles y el manifiesto

Todo este proceso natural e inconsciente sobre como clavar a una cebra, descrito en la sección anterior, gira alrededor de principios ágiles. Y estos principios a su vez se relacionan fuertemente con el manifiesto ágil.

  1. Simplicidad, el arte de maximizar el trabajo no realizado, es esencial.
    1. Algunos conocerán los principios KISS y YAGNI en programación.
    2. Así también algunos habrán escuchado NO DESPERDICIAR de Lean manufacturing
    3. LOTES PEQUEÑOS en cada iteración, de Lean Manufacturing
  2. Ciclo de retroalimentación
  3. Proceso iterativo e incremental

Estos son los más importantes desde mi punto de vista y tal vez los que más podemos notar en el día a día.

Origen de TDD en programación

Para darte una idea del origen real de TDD, voy a citar varias fuentes.

No teníamos manuales para ENIAC. Aprendimos a programar estudiando los diagramas de bloques lógicos. Que bendición. Desde el principio supe cómo funcionaban las computadoras. Nos ganamos el respeto de los ingenieros desde el principio porque realmente sabíamos lo que estábamos haciendo y pudimos depurar mejor que ellos porque teníamos nuestros programas de prueba y nuestro conocimiento de la computadora.

Betty Jean Jennings Bartik, ENIAC programmer 1946

El primer ataque al problema puede realizarse antes de comenzar la codificación. Para determinar completamente la precisión de las respuestas, es necesario tener un caso de verificación calculado a mano con el cual comparar las respuestas que luego serán calculadas por la máquina.

Esto significa que las máquinas de programas almacenados realmente nunca se utilizan para un problema de una sola vez. Siempre debe haber un elemento de iteración para que valga la pena. Los cálculos manuales se pueden realizar en cualquier momento durante la programación. Sin embargo, con frecuencia las computadoras son operadas por expertos en computación para preparar los problemas como un servicio para ingenieros o científicos.

En estos casos, es muy deseable que el “cliente” prepare el caso de verificación, en gran parte porque tal procedimiento puede señalar errores lógicos y malentendidos entre el programador y el cliente. Si el cliente va a preparar la solución de prueba, lo mejor para él es comenzar mucho antes del problema real, ya que para cualquier problema importante se necesitarán varios días o semanas para calcular la prueba

Digital Computer Programming, D.D. McCracken, 1957

Otro dato, de la época de John Von Neumann, en una entrevista realizada a Gerald. M. Weingberg por Michael Bolton

Jerry: No llamábamos a esas cosas por esos nombres en ese entonces, pero si miras mi primer libro (Computer Programming Fundamentals, Leeds & Weinberg, first edition 1961 —MB) y muchos otros desde entonces, verás que siempre fue así como pensabamos que era la única forma lógica de hacer las cosas. Lo aprendí de Bernie Dimsdale, quien lo aprendió de von Neumann.

… luego me encontré con Bernie (en 1957), quien me mostró cómo la gente verdaderamente inteligente hacía las cosas. Mi ego estaba un poco en shock al principio, pero luego me di cuenta de que si von Neumann hacía las cosas de esta manera, yo debería hacerlo.

John von Neumann fue mucho más inteligente de lo que yo seré jamás, o de lo que la mayoría de la gente será, esto significa es que debemos aprender de él …

Geral M. Weinberg

La descripción original de TDD estaba en un libro antiguo sobre programación. El libro decía, tome la cinta de entrada, escriba manualmente lo que espera en la cinta de salida, luego programe hasta que la cinta de salida real coincida con la salida esperada.

Después de escribir el primer marco xUnit en Smalltalk, recordé haber leído esto y lo probé. Ese fue el origen de TDD para mí. Al describir TDD a programadores mayores, a menudo escucho: “Por supuesto. ¿De qué otra manera podrías programar? ” Por lo tanto, me refiero a mi papel como “redescubrir” TDD.

Kent Beck

Si analizamos un poco estos últimos datos, en esa época se necesitaban ejecutar pruebas y resolver el problema en papel antes de correr el programa en la computadora porque era muy tardado volver a ejecutar el programa después de una falla ya sea por el tiempo de “ejecución” o porque las máquinas de esa época simplemente no eran tan sofisticadas como las de hoy en día.

Todo esto nos indica la importancia de las pruebas y así no retrasar el tiempo necesario para que la solución funcione correctamente y con menos esfuerzo, en la actualidad no ha cambiado mucho, eso sí, tenemos otros problemas, además el software que se desarrolla hoy en día tiene mayor escala y las funcionalidades son más sofisticadas.

Otro punto que nos enseñan estos datos, es que la comunicación entre los involucrados desde un principio es importante para evitar errores lógicos y malentendidos entre el cliente y el programador. Aquí los clientes también pueden ser  usuarios, personas de UX y product owners.

Lo descrito por Kent Beck es muy interesante, programadores más viejos están de acuerdo en que no existe una mejor manera de programar que la de escribir las pruebas primero.

En conclusión, estos datos nos abre los ojos a que las pruebas siempre han sido parte del proceso de diseño y codificación. Y que se hacen lo más antes posible (test-first programming)

OK, ¿Qué es TDD?

Es una disciplina que te permite eliminar el miedo a modificar el código de un software, lo que resulta en la limpieza constante del código, por lo que se asegura que el software escale de manera fluida, sin retrasos y dolores de cabeza. Permitiendo tener un software lo suficientemente flexible para poder adaptarse a cualquier cambio.

TDD es una práctica ágil, por consiguiente basada en principios ágiles que nos permite tener una guía en el desarrollo de software para nunca perder el enfoque.

TDD se basa en la mentalidad de prevenir defectos en lugar de resolverlos después, es obvio que no se puede prevenir todos los casos, pero si un gran número con un conjunto de pruebas bien hechas.

Históricamente hablando, ha probado ser en la gran mayoría de los casos, la mejor manera de crear productos de calidad. Significa Desarrollo guiado por pruebas (Test Driven Development), pero como mencionamos antes, la palabra especificación, la describe mejor, algo así como SDD, Specification Driven Development.

Red-Green-Refactor

En la práctica, consiste en tres pasos segun Kent Beck:

  1. RED. Escribe una pequeña prueba que no funcione, tal vez ni siquiera compile al principio
  2. GREEN. Haz que la prueba funcione rápidamente, cometiendo los pecados necesarios en el proceso.
  3. REFACTOR. Elimina todo el código duplicado creado

Ahora bien, cuáles son los beneficios principales:

  • Ciclo de retroalimentación y comunicación
  • Crear calidad, no medirla
  • Herramienta de diseño
  • Elimina el miedo a cambiar o mejorar el código
  • Documentación precisa

TDD como ciclo de retroalimentación y comunicación

Las organizaciones que diseñan sistemas (en el sentido amplio) están limitadas a producir diseños que son copias de las estructuras de comunicación de dichas organizaciones.

Melvin E. Conway, 1968

Individuos e interacciones sobre procesos y herramientas

Manifiesto ágil

Un ciclo de retroalimentación es muy importante para todo lo que hacemos, entre más pronto tengamos retroalimentación, más pronto podemos reaccionar y corregir nuestras acciones.

Cualquier metodología, framework o proceso ágil tiene como uno de sus elementos principales uno o varios ciclos de retroalimentación. Por ejemplo, en scrum, cada iteración llamada sprint es un ciclo de retroalimentación, las retroespectivas es claramente otro. Todos los días el daily es un ciclo retroalimentación. Cada release es un ciclo retroalimentación.

Estos ciclos de retroalimentación nos permiten tener una excelente comunicación y de forma constante.

TDD es lo mismo que BDD

Pero hablando en conjunto, desde el punto de vista técnico y de negocio, trasladado al código, el cual es el que nos permite cumplir con el comportamiento deseado de una determinada aplicación, ¿Existe algún ciclo de retroalimentación? ¿Qué nos permita corregir errores lo más pronto posible?

Respuesta ante el cambio sobre seguir un plan

Manifiesto ágil

Claro que sí, existen dos prácticas muy útiles para esto, una se llama BDD y la otra TDD, estas prácticas responden dos preguntas muy importantes:

  1. ¿Estamos construyendo el software correcto?, ¿El que el usuario final necesita?
  2. ¿Estamos construyendo correctamente el software, ¿Con la suficiente flexibilidad que permita adaptarse a las nuevas necesidades de los usuarios?

Aunque BDD y TDD parecen que son dos cosas diferentes, en realidad son lo mismo, TDD se empezó a utilizar primero, de hecho se creaban pruebas de aceptación, de integración y unitarios usando TDD. Luego, apareció ATDD y BDD (con ayuda de DDD) como extensiones de TDD.

En realidad BDD aporta a TDD:

  1. La mejora en la retroalimentación y comunicación entre todo el equipo, programadores y no programadores
  2. Comportamientos documentados con mayor claridad y precisión

Lo que escribimos en código de prueba son el reflejo de las especificaciones, el objetivo primordial de las pruebas no es verificar exactamente que una clase o método se ejecute correctamente, sino cómo se comporta según el deseo implícito de los usuarios finales, y este deseo implícito se plasma explícitamente en las especificaciones creadas antes de empezar escribir código de programación. 

Lo anterior es muy importante porque nos da el objetivo y el foco correcto a nuestro desarrollo.  Esta idea la podemos decir de las siguientes formas, desarrollo guiado por:

  • Especificación.
  • El dominio
  • Comportamiento
  • Pruebas, la definición más conocida y que lamentablemente genera más confusión.

TDD para crear calidad, no para medirla

La palabra Testing (Prueba) en el mundo de QA (Quality assurance), quiere decir probar después de que el software está desarrollado, probar y probar hasta comprobar que el software no tiene defectos. Debido a esto, las pruebas de QA son una forma de medir la calidad de un producto, pero no es una forma de construir un producto con calidad.

El ciclo de retroalimentación que nos da el escribir y terminar una funcionalidad y luego probar es ineficiente porque la retroalimentación se obtiene muy tarde. Es posible trabajar en algo equivocado por minutos, horas y hasta días, a veces ese trabajo tiene que ser desechado o mínimo con muchos cambios.

Cuando la retroalimentación se retrasa mucho tiempo, por ejemplo, después de un ciclo de pruebas por parte de QA, el desarrollador encargado no tiene el contexto o no lo recuerda bien. Y esto genera más gastos, porque una vez reportado por QA se debe de encontrar la fuente del defecto y replicarlo, luego entender el problema, entender el código relacionado y además el tiempo que se tome corregirlo. Y otra vez QA prueba y reporta si el bug ha sido arreglado o no.

De nuevo el principio de Lean manufacturing sobre trabajar sobre cosas simples y pequeñas, no esperar a encontrar errores o mitigarlos hasta el final de la cadena de producción, sino en cada pequeña etapa del proceso tener uno o más ciclos completos de retroalimentación.

Ayuda a devops

Esto último va de la mano con la integración continua y despliegue continuo, si las pruebas fallan, no se puede establecer una integración y mucho menos un despliegue a producción.

Dado que un ciclo de retroalimentación temprana sucede en varios niveles del software, las incidencias aparecen antes de una integración y también mucho antes de un despliegue.

Claro que nunca se podrá mitigar todas los bugs o incidencias, pero por supuesto que se puede disminuir en una gran proporción, esto de igual manera resulta en reducción de costos, tiempo y esfuerzo.

El ambiente en los equipos se vuelve productivo, mejora la comunicación y seguridad en que de verdad se está entregando un producto de calidad, esto produce estimaciones más precisas, seguras, y honestas.

TDD como herramienta de diseño

Colaboración con el cliente sobre negociación contractual

Manifiesto ágil

Al escribir las pruebas primero (test-first programming) nos enfocamos en que el código de producción sea accesible desde el código de pruebas y sea fácil de probar. Esto quiere decir que desde un inicio nos preocupamos por el diseño y la arquitectura de nuestro código de producción, porque para que nuestro código de producción sea accesible y fácil de probar debe estar desacoplado.

Al escribir las pruebas, nuestra perspectiva de programador cambia, ahora pensamos en como otros programadores van a usar la API de nuestra funcionalidad antes de crearla, también desde la perspectiva de negocio porque cuando escribimos nuestras pruebas, a menudo nuevas dudas surgen que debemos indagar con personas que no son necesariamente programadores (muchas veces con cliente y usuarios).

Cada una de nuestras pruebas deben ejecutarse independientemente de las otras, en  nuestro esfuerzo de hacer que las pruebas se ejecuten independientemente, mejoramos el diseño del software, por ejemplo, una prueba unitaria corre dentro de un ambiente que no es real, se ejecuta sobre lo que llamamos test fixtures y sus dependencias (muchas de las cuales serán código de producción) deben ser lo bastante flexibles de tal manera que permitan ser sustituidas, invocadas y verificadas fácilmente. Esto permite crear un software con alta cohesión y bajo acoplamiento, es decir, con un buen diseño y una buena arquitectura.

Nuestros diseños deben consistir en muchos componentes altamente cohesivos y débilmente acoplados, solo para facilitar las pruebas.

Kent Beck

El código de pruebas debe desarrollarse con la más alta calidad posible, deben ser fácil de entender y fácil de ejecutar de manera independiente, y al enfocarnos en este aspecto, el código de producción creado también resulta de la más alta calidad posible. Sin perder de vista que esto sucede paso a pasito, en un proceso enfocado a la simplicidad, iterativo e incremental.

El resultado de un buen diseño, también resulta en que las modificaciones de código se hacen mucho más rápido, y esto quiere decir que no necesitas quedarte horas extras programando, tendrás más tiempo personal, que puedes compartir con tu familia, hijos, con tu pareja (o amante), etcétera.

TDD elimina el miedo a modificar el código

¿Por qué la mayoría de los programadores tienen miedo de hacer cambios a su código? ¡Tienen miedo de romper el código! ¿Por qué tienen miedo de romper el código? Porque no tienen pruebas.

Robert C. Martin, The Clean Coder: A Code of Conduct for Professional Programmers

Las pruebas son más importantes que el código de producción porque permiten que el sistema se vuelva flexible, de otra manera el miedo a la modificación del código crece, porque se teme romper la funcionalidad, y entonces el software ya no es adaptable, poco a poco, entre más evoluciona, menos flexible se vuelve por miedo a realizar modificaciones que rompan el producto.

¿No te ha pasado en algún proyecto, donde necesitas hacer unas modificaciones al código, y existen partes que mejor ni las tocas por miedo de romper alguna funcionalidad?, porque realmente no estás seguro de lo que esa parte del código hace y no tienes un conjunto de pruebas que respalde tus cambios.

¿Qué es código legacy?

Codigo que los programadores tienen miedo cambiar

Eli Lopia CEO de typemock

Código sin pruebas

Michael C. Feather

TDD permite mitigar el miedo de modificar tu código o el de otra persona. ¿Cómo puedes tener seguridad de que las funcionalidades que desarrollas tienen la calidad suficiente para decir que está terminado? Sin un conjunto de pruebas no tienes esa seguridad, y como ya hemos comentado antes, esperar retroalimentación hasta el ciclo de pruebas de un equipo de QA, es demasiado tarde.

Cuando se tiene un buen conjunto de pruebas, no tienes miedo de hacer los cambios necesarios, porque si rompes algo, las pruebas te lo advierten casi en tiempo real mientras estás realizando las modificaciones.

Individuos e interacciones sobre procesos y herramientas

Manifiesto ágil

Segun Ken Beck el miedo tiene los siguientes efectos, te hace:

  • Inseguro sobre el código que escribes
  • Querer comunicar menos
  • Tímido a la retroalimentación
  • Gruñón

Ningún efecto de arriba es de ayuda a la hora de programar y menos cuando nos enfrentamos a un problema complicado. Así que Kent Beck recomienda los siguientes puntos usando TDD:

  • En lugar de dudar de tu código, empieza a aprender cosas concretas lo más rápido posible. Paso a pasito, lotes pequeños y de manera iterativa e incremental con el ciclo red-green-refactor.
  • En lugar de quedarte callado, comunícate más claramente. Al usar TDD aumentas la calidad y por consiguiente estás dispuesto a comunicar dudas o problemas que enfrentas a la ahora de programar
  • En lugar de evitar retroalimentación, busca ayuda, y retroalimentación concreta.
  • (Sobre lo gruñón, estas por tu cuenta). Pero con más seguridad en tu código, menos problemas y más tiempo personal, seguro que tu nivel de gruñón bajará.

TDD como documentación precisa

Software funcionando sobre documentación extensiva

Manifiesto ágil

Para tener una documentación detallada es necesario mucho tiempo y esfuerzo porque la documentación siempre cambia conforme se le agregan nuevas funcionalidades o se modifican las ya existentes. Entonces ese tiempo y esfuerzo mejor se invierte en obtener software funcionando que puede ser presentado al cliente y obtener retroalimentación. Es muy difícil mantener sincronizada la documentación con el verdadero funcionamiento (con el código), con el tiempo la documentación miente sobre la funcionalidad, la única fuente de verdad es el código, el código no miente.

La mejor documentación e instrucciones de como funciona una pieza del sistema se encuentran en las personas y el código que ellas crean. Es de valor inigualable poner énfasis en la excelencia técnica y al buen diseño para mejorar la agilidad, es decir, código limpio, bien diseñado y utilizando TDD y BDD. De esta forma no necesitas llegar al detalle de alguna pieza del sistema, simplemente la usas con seguridad del resultado debido al buen diseño y a la calidad de la misma, lo que por supuesto te ahorra muchísimo tiempo. Claro que esto no se puede lograr sin las personas, sin su disciplina y auto organización.

Para ponerlo más claro, cuando tienes la disciplina de hacer TDD, cada una de las pruebas que creas, describe perfectamente como cada función o método, clase y/o componente se utiliza, de una manera tan precisa que si algo va mal cuando se está modificando, al menos una de las pruebas fallara casi al instante.

Cuando realizas pruebas de métodos y funciones, tienes que describir que parámetros reciben y que resultados regresan ¿Qué más documentación necesitas? Tampoco digo que nunca se haga documentación, claro que si, pero es una inversión de tiempo, dinero y esfuerzo, que puedes disminuir considerablemente y que puedes posponer hasta las etapas más estables del producto, cuando se sabe que su funcionalidad cambiará poco o en intervalos más largos de tiempo.

Al final, como programadores, siempre nos aseguramos o solo confiamos al 100% sobre como funciona cualquier API de software hasta que le echamos un ojo al código y lo probamos. Y sería estupendo que la funcionalidad del código esté descrita detalladamente a través de un conjunto de pruebas.

Referencias

https://arialdomartini.wordpress.com/2012/07/20/you-wont-believe-how-old-tdd-is/

http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF

https://www.developsense.com/blog/2011/01/jerry-weinberg-interview-from-2008/

https://associationforsoftwaretesting.org/2014/11/02/how-to-sell-tdd-to-x/

https://www.computerworld.com/article/2470893/jean-bartik–last-of-the-original-eniac-programmers–86.html

https://en.wikipedia.org/wiki/ENIAC

https://es.wikipedia.org/wiki/Jean_Jennings_Bartik

https://www.quora.com/Why-does-Kent-Beck-refer-to-the-rediscovery-of-test-driven-development-Whats-the-history-of-test-driven-development-before-Kent-Becks-rediscovery

https://agileforall.com/history-of-tdd-as-told-in-quotes/

Test-Driven development: by example

Paradigma de programación en JavaScript

Paradigma de programación en JavaScript

Por | Nov 28, 2020 | Agilidad, JavaScript, Node.js, Programación Intermedia | comentarios

¿Qué es un paradigma de programación?

El modelo o mapa de como vemos el mundo real, eso es un paradigma, es una manera de ver y hacer las cosas. Siguiendo esta lógica, un paradigma de programación no es más que una forma de ver y crear código de programación.

Los paradigmas son poderosos porque crean los cristales o las lentes a través de los cuales vemos el mundo.

Stephen R. Covey

Existe tres principales paradigmas de programación utilizados en la actualidad y que en JavaScript siempre han existido desde su primera versión.

  • Paradigma de programación Estructurada
  • Orientada a objetos
  • Funcional

Ahora bien, si nos apegamos a la frase de Stephen R. Covey, sobre que los paradigmas crean las lentes a través de los cuales vemos el mundo. Imaginemos que los tres paradigmas anteriores, cada uno, son un par de lentes que nos ponemos a la hora de programar y que podemos cambiar esos lentes según nuestras necesidades visuales (de programación o solución de problemas).

Paradigma de programación estructurada

Origen

En el año 1954 apareció el lenguaje de programación FORTRAN, luego en 1958 ALGOL y en 1959 COBOL. Tiempo después Edsger Wybe Dijkstra en 1968 descubre el paradigma de programación estructurada, decimos que “descubre” porque en realidad no lo inventaron. Aunque este paradigma de programación se formalizó tiempo después de la aparición de estos lenguajes de programación, era posible hacer programación estructurada en ellos.

Dijkstra reconoció que la programación era difícil, y los programadores no lo hacemos muy bien, de lo cual estoy totalmente de acuerdo. Un programa de cualquier complejidad tiene muchos detalles para el cerebro humano. De hecho la neurociencia nos indica que la mente enfocada solo puede trabajar con cuatro datos a la vez, cuanto mucho. Por esta razón, si se descuida un pequeño detalle creamos programas que parecen funcionar bien, pero que fallan en formas que uno nunca se imagina.

Pruebas

La solución de Dijkstra fue utilizar pruebas, solo que estas pruebas usaban mucho las matemáticas, lo cual era bastante difícil de implementar. Durante su investigación encontró que ciertos usos de GOTO hacían difícil descomponer un programa grande en piezas más pequeñas, no se podía aplicar “divide y vencerás”, necesario para crear pruebas razonables.

Secuencia, selección e iteración

Patrones de la programación estructurada
Patrones de la programación estructurada

Böhm y Jacopini probaron dos años antes que todos los programas pueden ser construidos por solo tres estructuras: secuencia, selección e iteración. Dijkstra ya conocía estas tres estructuras y descubrió que estas mismas son las necesarias para hacer que cualquier parte del programa sea probado. Es aquí donde se formaliza el paradigma de programación estructurada.

Edsger nos indica que es una mala práctica usar GOTO y sugiere usar mejor las siguientes estructuras de control:

  • If, then, else (selección)
  • do, while, until (iteración o repetición)

Descomposición de pequeñas unidades fáciles de probar

Hoy en día la mayoría de los lenguajes de programación utilizan la programación estructurada, JavaScript utiliza este tipo de programación. El ejemplo más sencillo son las condiciones if.

const EDAD_MINIMA = 18;
if (edad >= EDAD_MINIMA) {
	// hacer algo porque es mayor que 18
} else {
	// Hacer otra cosa en caso contraio
}

Y si lo aislamos en una función, tenemos una descomposición de funcionalidades o unidades que pueden ser probadas con mayor facilidad. En la siguiente sección veremos la importancia de tener una unidad completamente probable

const EDAD_MINIMA = 18;
function esMayorEdad(edad) {
  if (edad >= EDAD_MINIMA) {
     return true;
  } else {
     return false;
  }
}

Con esta condición tenemos un control directo de lo que puede suceder si la edad es mayor o igual a 18, y también en el caso de que la edad sea menor.

Tampoco seamos tan estrictos, seguro que la sentencia GOTO tiene sus méritos y tal vez era muy eficiente en algunos casos, pero pienso que para evitar malos usos que probablemente causaban desastres, Dijkstra recomendó dejar de usar GOTO.

Pruebas, divide y vencerás

La programación estructurada nos permite aplicar la filosofía de “divide y vencerás”, porque nos permite crear pruebas de pequeñas unidades, hasta tener todo el programa cubierto. La solución matemática de Wybe Dijkstra nunca se construyo, precisamente por su dificulta de implementación. Y lamentablemente en nuestros días aún existen programadores que no creen que las pruebas formales sirven para crear software de alta calidad.

Y digo crear, porque verificar el correcto funcionamiento después de crear, no es más que una simple medición y se pierde la oportunidad de reducir tiempo y dinero.

Método científico, experimentos e impirismo

Método científico, experimentos y pruebas
Método científico, experimentos y pruebas, por ThisIsEngineering Raeng en unsplash

La buena noticia es que el método matemático no es la única forma de verificar nuestro código, también tenemos el método científico. El cual no puede probar que las cosas sean absolutamente correctas desde el punto de vista matemático. Lo que si se puede hacer es crear experimentos y obtener resultados suficientes para verificar que nuestras teorías funcionan. Dado que nuestras teorías funcionan sobre estos experimentos, entonces concluimos que son lo suficientemente “correctas” para nuestros propósitos de validación.

Si la teoría es fácilmente validada como falsa, entonces es momento de modificarla o cambiarla. Así es el método científico y así es como actualmente se hacen las pruebas:

Primero establecemos nuestra teoría (escribimos la prueba), después construimos los experimentos (escribimos código de producción) y finalmente verificamos (corremos la prueba) y repetimos este ciclo hasta tener evidencia suficiente.

¿Esto no te suena a una práctica ágil actual llamada TDD?

Las pruebas muestran la presencia, no la ausencia, de defectos

Edsger Wybe Dijkstra dijo “Las pruebas muestran la presencia, no la ausencia, de defectos”. Ósea, un programa puede ser probado incorrecto mediante pruebas, pero no puede ser probado correcto. Todo lo que podemos hacer con nuestras pruebas es validar que nuestro programa funciona lo suficiente bien para nuestros objetivos. Pero nunca podemos estar cien por ciento seguros de la ausencia de defectos.

Si nunca podemos estar cien por ciento seguros que nuestro código es correcto, aun con sus pruebas, ¿Qué nos hace pensar que sin pruebas entregamos un programa con la suficiente validez para afirmar que no se comete conscientemente alguna negligencia?

El control directo

La programación estructurada nos enseña sobre el control directo, es decir, controlar el flujo secuencial de las operaciones a través de las estructuras de control, sin descuidar la recomendación de Wybe Dijkstra sobre GOTO. Esta recomendación también es aplicable a sentencias que cambian drásticamente el flujo normal de las operaciones, por ejemplo un break dentro de un ciclo for anidado, ese break rompe el control directo porque complica abruptamente el entendimiento del algoritmo. Tampoco seamos puristas, seguro habrá casos que necesites de estas sentencias, pero de primera instancia, trata de evitarlas.

En conclusión, el paradigma de programación estructurada nos enseña:

El control directo, claro y explicito de lo que hace un pedazo de código

Paradigma de programación orientada a objetos

¿Surgido de funciones?

El paradigma de programación orientada a objetos se descubrió en 1966 por Ole Johan Dahl y Kristen Nygaard cuando desarrollaban simula 67. Dos años antes de la programación estructurada y su adopción por la comunidad de programadores fue tiempo después. En 1967 se lanzó Simula 67, Simula fue el primer lenguaje de programación orientado a objetos,  básicamente le agregó clases y objetos a ALGOL, inicialmente Simula iba a ser una especie de extensión de ALGOL.

Durante el desarrollo de Simula, se observó que la ejecución de una función de ALGOL necesita de ciertos datos, los cuales se podían mover a una estructura de árbol. Esta estructura de árbol es un Heap.

El heap permitía declarar variables locales de la función que pueden existir incluso después de que la función regrese un valor. ¿Esto último no les suena a lo que es closure en JavaScript?

La función padre se convierte en un constructor, las variables locales se convierten en las propiedades y las funciones hijas (anidadas) en sus métodos. De hecho este patrón es aún muy utilizado por Javacript para crear módulos y usar herencia funcional. También esto describe como funcionan las clases en Javascript, por detrás son funciones.

Esparcimiento del polimorfismo

Todo esto ayudó mucho a que se implementará el polimorfismo en los lenguajes de programación orientados a objetos. Ole Johan Dahl y Kristen Nygaard inventaron la notación:

objeto.funcion(parametro)

La ejecución de funcion que pertenece a objeto, pero más importante, le pasamos un mensaje a través de parámetros desde la primera parte del código a la segunda parte localizada en un objeto diferente.

La biología molecular y el paso de mensajes

Paso de mensajes entre células
Paso de mensajes entre células, Imagen modificada de “Signaling molecules and cellular receptors: Figure 1,” por OpenStax College, Biology (CC BY 3.0).

Tiempo después se creó Smalltalk, un lenguaje de programación orientado a objetos mucho más sofisticado y moderno, a cargo de este proyecto estaba Alan Kay. A esta persona se le atribuye la definición formal de la programación orientada a objetos.

La principal influencia en la programación orientada objetos de Alan Kay fue la biología, él es licenciado en biología. Aunque es obvio que fue influenciado por Simula, la influencia de LISP (lenguaje de programación funcional) no es tan obvia.

Desde un inicio él pensaba en los objetos como células interconectadas en una red, de la cual se podrían comunicar mediante mensajes.

Alan Kay comentó lo siguiente:

Lamento que hace tiempo haya acuñado el término Objetos para la programación porque hizo que las personas se enfocaran en la parte menos importante. La gran idea es “Envío de mensajes“.

Alan Kay

Mi Ingles es malo así que pueden revisar el texto original aquí.

Mejor composición de objetos sobre herencia de clases

Smalltalk permitió también la creación de Self, creado en Xerox Parc y luego migrado a Sun Microsystems Labs. Se dice que Self es una evolución de smalltalk.

En este lenguaje de programación se introdujo la idea de prototipos, eliminando la utilización de clases para crear objetos, este lenguaje utiliza los objetos mismos para permitir que un objeto reutilice las funcionalidades de otro.

Self es un lenguaje rápido y en general se le conoce por su gran rendimiento, self hizo un buen trabajo en sistemas de recolección de basura y también utilizaba una maquina virtual para administrar su ejecución y memoria.

La máquina virtual Java HotSpot se pudo crear gracias a Self. Lars Bak uno de los últimos contribuidores de Self, se encargó de la creación del motor de Javascript V8. Debido a la influencia de Self tenemos hoy en día el motor de JavaScript V8, el cual lo utiliza node.js, mongoDB y Google Chrome internamente.

Self seguía una de las recomendaciones del libro Design Patterns: Elements of Reusable Object-Oriented Software, mucho antes de que saliera publica esta recomendación:

Mejor composición de objetos a herencia de clases.

Design Patterns: Elements of Reusable Object-Oriented Software

Ejemplo

Actualmente Javascript utiliza prototipos para la reutilización de código, se podría decir que usa composición, en lugar de herencia. Veamos un ejemplo:

const persona = {
    saludar () {
      return 'Hola'
    }
};
// se crea un programador con el prototipo igual al objeto persona
const programador = Object.create(persona);
programador.programar  = () => 'if true';
const saludo = programador.saludar();
const codigo = programador.programar();
console.log(saludo); // 'Hola'
console.log(codigo); // 'if true'

El objeto programador se basa en el prototipo de `persona`. No hereda, solo reutiliza directamente la funcionalidad de `persona`.

JavaScript surge poquito después de JAVA, en el mismo año. JavaScript tomo influencias de Self, y a su vez Self fue influido por smalltalk.

La sintaxis de clases actuales en Javascript no es más que una fachada, bueno un poco más exacto son una evolución de las funciones constructoras, pero internamente, su base, son las funciones y los prototipos.

La comunicación con el paso de mensajes

Como ya vimos, el origen de la programación orientada objetos tiene su origen en las funciones, y la idea principal siempre ha sido la comunicación entre objetos a través del paso de mensajes. Podemos decir que La programación orientada a objetos nos habla del paso de mensajes como pieza clave para la comunicación de objetos, por ejemplo, cuando un método de un objeto invoca el método de otro.

objeto.funcion(parametro);

En conclusión, el paradigma de programación orientado a objetos, nos enseña:

El paso de mensajes para la comunicación entre objetos

Paradigma de programación funcional

Cálculo lambda

Imagen tomada de https://www.slideshare.net/FASTPresentations/introduction-to-lambda-calculus-using-smalltalk-by-facundo-javier-gelatti

La programación funcional es el paradigma de programación más viejo, de hecho su descubrimiento fue mucho antes de la programación para computadoras, fue descubierto en 1936 por Alonzo Church, cuando invento el cálculo lambda, base del mismo problema a resolver de su alumno Alan Turing.

Como dato curioso el símbolo del cálculo lambda es:

λ

El primer lenguaje basado en programación funcional fue LISP, creado por John McCarthy. Como vimos anteriormente, Alan Kay también tomo influencias de LISP para crear Smalltalk, con esto podemos comprobar que los paradigmas de programación pueden estar unidos y su relación entre ellos surge de la idea de como resolver problemas de manera más eficiente, no están peleados, ni separados, buscan el mismo objetivo y de alguna manera evolucionan en conjunto.

La base del cálculo lambda es la inmutabilidad, más adelante revisaremos este concepto.

Similitudes con los paradigmas OO y estructurada

Como vimos en el paradigma de programación estructurada, podemos descomponer nuestros programas en unidades más pequeñas llamadas procedimientos o funciones. Dado que la programación funcional es el paradigma más viejo, podemos decir que el paradigma de programación estructurada también se apoya en la programación funcional.

Ahora bien, si analizamos un poco la notación objeto.funcion(x) que vimos en la sección del paradigma de programación orientada a objetos, no es muy diferente de funcion(objeto, parametros), estas dos lineas de abajo son iguales, la idea fundamental es el paso de mensajes, como nos indica Alan Kay.

objeto.funcion(parametro);
funcion(objeto, parametro);

Smalltalk usa el “El Modelo Actor”, el cual dice que los actores se comunican entre ellos a través de mensajes.

Por otro lado tenemos a LISP, el cual tiene un “Modelo despachador de funciones” que actualmente le llamamos lenguaje funcional, estos modelos son idénticos, porque las funciones y métodos lo que hacen es enviar mensajes entre actores.

Un ejemplo de esto es cuando una función llama a otra función o cuando se invoca el método de un objeto, lo que sucede es que existen actores y se comunican entre ellos a través de mensajes.

De nuevo el paso de mensajes

Entonces podemos recalcar que la idea principal de la POO es el envío de mensajes y que no es muy diferente de la programación funcional, de hecho según lo que ya establecimos en las secciones anteriores, POO nació de una base funcional. Y aquí es importante remarcar lo que dijo Alan Kay Co-creador de SmallTalk:

Lamento que hace tiempo haya acuñado el término Objetos para la programación porque hizo que las personas se enfocaran en la parte menos importante. La gran idea es “Envío de mensajes“.

Alan Kay

A partir de los modelos de comunicación entre mensajes de Smalltalk y LISP, se creó Scheme.

Scheme tiene la bondad de usar Tail recursion y closure para obtener un lenguaje funcional, closure permite tener acceso a las variables de una función externa aun cuando esta ya haya regresado algún valor. Esto es el mismo principio que origino a la programación orientada a objetos a cargo de Ole Johan Dahl y Kristen Nygaard. ¿Recuerdan la pregunta de closure en Javascript?

Javascript usa mucho closure en su paradigma de programación funcional. JavaScript tomó influencias de Scheme, a su vez Scheme fue influido por LISP.

Sin efectos colaterales

La base del cálculo lambda es la inmutabilidad, por consiguiente, la inmutabilidad también es la base del paradigma de programación funcional.

Nosotros como programadores funcionales debemos seguir este principio y limitar las mutaciones de objetos lo más que se pueda para evitar efectos colaterales.

Repito, la idea principal de la programación funcional es la inmutabilidad, la cual te permite crear tus programas con menos errores al no producir efectos colaterales difíciles de controlar.

Como ejemplo, supongamos que tenemos un objeto persona y queremos “cambiar” el nombre, lo más obvio seria modificar la propiedad nombre directamente, pero que pasa si ese objeto es utilizado en otra parte y se espera que nombre sea “Jaime”, es por eso que en lugar de cambiar la propiedad nombre, solo creamos un nuevo objeto persona con diferente nombre, sin modificar el original.

function cambiarNombre(nombre, persona) {
  return {
    nombre: nombre,
    edad: persona.edad
  }
}
const jaime = { nombre: 'Jaime', edad: 30 };
const juan = cambiarNombre('Juan', jaime);
console.log(jaime); // { nombre: 'Jaime', edad: 30 }
console.log(juan); // { nombre: 'Juan', edad: 30 }

Aquí encontrarás más detalles sobre los principios fundamentales de programación funcional:

Introducción a programación funcional

Por último, el paradigma de programación funcional nos enseña:

Sin efectos colaterales, para una expresión clara y menos propensa a errores

Conclusión

Es importante destacar que si los tres paradigmas de programación fueron implementados entre los años 1958 con LISP (programación funcional) y Simula (programación Orientado a objetos) en 1966, y el descubrimiento del paradigma de programación estructurado en 1968, en solo un lapso de 10 años existió la innovación de los paradigmas de programación, y realmente nuevos paradigmas no han surgido, al menos que no sean basados en estos tres principales.

Ahora mismo ya han pasado más de 60 años, lo que nos dice de la importancia y la firmeza que tienen a pesar del tiempo transcurrido.

  • Paradigma de programación funcional (1958, ya implementado en un lenguaje de programación para computadoras, recordemos que fue descubierto en 1936)
  • Orientado objetos (1966)
  • Estructurada (1968)

La implementación de estos tres paradigmas desde el inicio en el interior de JavaScript han hecho que este lenguaje de programación tenga el éxito global de hoy en día. Y nos comprueba lo valioso de combinar los paradigmas al escribir nuestros programas.

JavaScript es en lenguaje de programación multiparadigma, por lo que se puede combinar los paradigmas para crear un código mucha más eficiente y expresivo usando:

  • El control directo, claro y explicito de lo que hace un pedazo de código
  • El paso de mensajes para la comunicación entre objetos
  • Sin efectos colaterales, para una expresión clara y menos propensa a errores

Referencias

https://en.wikipedia.org/wiki/Structured_programming

https://en.wikipedia.org/wiki/Structured_program_theorem

http://wiki.c2.com/?AlanKayOnMessaging

https://www.slideshare.net/FASTPresentations/introduction-to-lambda-calculus-using-smalltalk-by-facundo-javier-gelatti

Libro Clean architecture

es_MXES_MX
en_USEN es_MXES_MX