Algo no encaja

Una forma de interpretar la filosofía TDD (Desarrollo orientado a pruebas) es como una metodología que bien planteada lleva “la problemática del resultado” hasta los desarrolladores.

¿Qué es la problemática del resultado? La problemática del resultado es el requerimiento que se le hace a un responsable de proyecto de que el producto tiene que estar. Esta definición parece una afirmación obvia pero encierra uno de los grandes problemas del desarrollo de proyectos. Por su parte el responsable siente como su deber que el producto este listo en un plazo (es decir ve todo el proyecto) mientras que las personas que están a su cargo no lo entienden así ya que entienden que están desarrollando un producto pero solo se sienten responsables de la tarea que estén realizando.

Cuanto mas bajo este una persona en el escalafón del proyecto sus tareas son mas cortas y por lo tanto esa persona ve como su trabajo ya esta hecho cuando termina una tarea determinada (es decir ve solo la tarea que está haciendo en ese momento).

Volviendo con TDD, si la forma de marcar el fin de la tarea de un subordina fuese que “lo que ha desarrollado” cumpla unos determinados ejemplos y no el simple hecho de decirle:”¿has terminado? ” y el diga:”si” entonces no solo conviertes algo subjetivo en al cuantificable (lo subjetivo es el “si creo que esta terminado” y lo cuantificable es un test que se cumple o no se cumple y por lo tanto es cuantificable) es que además haces que el desarrollador entienda que es la problemática del resultado.

YAGNI

La programación extrema, y en general todos los métodos ágiles, sugieren que si algo no lo vas a utilizar no lo piques. Es decir, por ejemplo si se solicita una aplicación Java que sea una calculadora que sume y reste y todas las operaciones están en la clase Funciones.java entonces no se ha de implementar una función “multiplicar” en la clase Funciones.java porque no se ha pedido. Si en un futuro se necesita o lo solicita el cliente entonces ya se picara.

Esta filosofía se extrapola a componentes y frameworks. Se da a entender que al desarrollar componentes y frameworks se desarrolla más funcionalidad de la que se necesita.

Estoy de acuerdo que en algo tan simple como una “función“ no merece la pena y así se ahorra tiempo y dinero pero en algo como tan genérico como componentes y frameworks no lo estoy. El uso de componentes y frameworks, si se hacen correctamente, puede orientar la forma de programar y hacer más parecido el código de los distintos programadores que lo usen (mas mantenible) y orientado correctamente (evita que “lo mejor que le parezca al programador en ese momento” no sea la tónica de la programación). Lo que hay que hacer es que si realmente se quiere apostar por el uso de componentes y frameworks hay que molestarse un poco en leer la documentación asociada, seguir la guía de los desarrolladores, etc… Es decir, si se va a utilizar componentes y frameworks hay que hacerlo bien, siguiendo las recomendaciones de los fabricantes y leyendo documentación y no cogiendo el componentes o frameworks de cualquier manera y cuando no se comporta como se espera decir: “Este frameworks es una mierda ” (te suena, ¿verdad?)

Una ayuda con TDD

En esta página podéis encontrar un libro en castellano sobre TDD gracias a Carlos Bl´e Jurado.

http://www.dirigidoportests.com/el-libro