Design

Test Driven Development (actualización)

Veréis, llevo leyendo el blog de Joel Spolsky cerca de dos años ya, y siempre he considerado que cada opinión suya tiene un enorme valor. Podría decir que cada vez que el habla, yo asiento.

Si escribes un artículo criticando el Desarrollo dirigindo por las pruebas, que es una de las metodologías con más "buzz"1 del momento, esperas que un montón de gente no este de acuerdo o sencillamente piensen que te has vuelto loco... a fin de cuentas el "Test Driven Development" "mola" ¿no?

Dicho esto, cuando Joel y Jeff Atwood hablan de esas cuestiones y básicamente confirman lo que has dicho... bueno, debo decir que me siento halagado. Principalmente porque esos dos tienen un enorme impacto en internet, en segundo lugar porque normalmente coincido totalmente con ellos, y en tercer lugar... bueno, porque está bien tener razón... o por lo menos que la gente "popular" piense lo mismo que tu.

Respecto a lo que dicen (es una transcripción de uno de sus podcasts), bueno, ¿que puedo decir? Solo una pequeña cosa, al final Jeff dice:

...porque lo que importa es lo que entregas al cliente, y como de satisfecho está el cliente con lo que le has entregado. Hay muchas, muchas maneras de llegar ahí.

Bueno, eso es cierto pero, ¿qué tiene que ver con lo que estamos hablando? Todas las metodologías se diseñan teniendo eso en cuenta, todo el mundo quiere entregar un producto excepcional al cliente; bueno, de hecho todo el mundo quiere hacer dinero entregándole ese producto excepcional. Así que claro que hay muchas formas, de lo que hablamos es de elegir la mejor manera de hacerlo, eso es lo que las metodologías proporcionan, una forma de hacer las cosas, una estructura sobre como trabajar.

Al final, las metodologías son solo una parte de la ecuación. Otras partes includen el sentido común para adaptarse a cada situación, el conjunto de herramientas adecuadas y, principalmente, la gente que trabaja en el proyecto. De esa forma, no estoy diciendo que hacer pruebas unitarias es malo, todo lo contrario, hacerlas para todo es lo que es malo. ¿Por qué? Porque fallamos en utilizar nuestro sentid común para decirnos que debe ser probado y qué no necesita serlo.

Y ese es básicamente el problema con el Desarrollo dirigido por las pruebas, puesto que las pruebas dirigen el desarrollo, tienes que hacerlas para todo lo que necesita ser desarrollado, o de otra forma no "dirigirán"...

  1. 1. Buzz es un término ingles que informalmente significa cierta excitación ("a sense of excitement")

Introducción a la programación multihilo

Antes de empezar

En este articulo no hay ni una sola linea de código y no esta orientado a enseñar los entresijos especificos de la programación multihilo en este o aquel lenguaje sino a dar una pequeña introducción, centrandose fundamentalmente en el como y el sobre todo en el por qué y en el cuando.

¿Que es la programación multihilo?

En estos tiempos todos los sistemas operativos (excepto quizá los educacionales) son sistemas operativos multitarea, esto quiere decir que pueden ejecutar varias tareas o procesos simulataneamente. Esto no siempre fue así, el ms-dos era un sistema monotarea lo que quiere decir que tan solo una tarea podía ejecutarse en el sistema simultaneamente.

Antes de lanzarnos a explicar la programación multihilo es conveniente hacer un repaso a ciertas caraterísticas de los sitemas operativos.