Solucionar el problema y buen diseño

Imagen de http://www.nydailynews.com

 

Cuando tenemos que añadir una nueva funcionalidad en nuestra aplicación tenemos que pensar desde el principio en como vamos añadirla y en el diseño que vamos a utilizar para implementarlo. Con diseño quiero decir los nuevos objetos de tipo servicio que vamos a utilizar, los nuevos objetos de dominio, como vamos a conectar todo esto con el código actual y un largo etcétera.

Normalmente tenemos que pensar en el diseño desde el principio porque posteriormente nos va a resultar trabajo el hacerlo después. Por ejemplo, si nos damos cuenta al final que un patrón encaja perfectamente con la solución que hemos implementado tendremos que testear que la nueva funcionalidad sigue funcionando de la manera adecuada. Y si hay algún error tendremos que depurar el código para ver donde está el error. Ocasionando una gran pérdida de tiempo.

Si estamos utilizando lenguajes estáticos como Java los IDE como IntelliJ o Eclipse nos permiten hacer cambios de diseño de forma automática (como renombrado de clases) lo que hace que el cambio no provoque casi nunca que el código no funcione como deseemos. Pero posiblemente queramos asegurarnos que el cambio no ha provocado un problema, lo que hace que tengamos que testear la aplicación de forma manual.

En resumen, cuando estamos empezando a codificar una nueva funcionalidad tenemos que pensar en la solución y en un diseño porque los cambios en el diseño posteriormente son costosos.

 

Cuando empecé a practicar TDD lo hice porque estaba cansado de que cada vez que arreglaba un problema había añadido dos más o que en un futuro apareciera de nuevo el mismo problema.

Pero cuanto más he ido practicando TDD una de las ventajas que más me gustan es que puedo enfocarme en una sola cosa a la vez porque tengo fases en las que me enfoco solo en diseñar y hay fases en las que me enfoco solo en solucionar el problema / añadir la nueva funcionalidad.

Las fases de TDD son tres:

  • escribir un test que falle
  • añadir código para que el test pase
  • refactorizar

En la primera y segunda fase nos dedicamos principalmente a solucionar el problema porque cada test que añadimos es un paso adelante hacia la solución y porque el código que añadimos es el mínimo para que pase el test. No nos tenemos que preocupar en el diseño de nuestro aplicación. Hay una excepción que es cuando escribimos el primer test ya que en el primer test decidimos el nombre de la clase, su método y los parámetros de entrada y salida.

En la tercera fase hacemos pequeños cambios en el código que hacen que el diseño general vaya mejorando y evolucionando en el tiempo.

Así que tenemos una parte en la que nos enfocamos en solucionar el problema y otra en la que nos enfocamos en el diseño. Enfocándonos en una cosa a la vez. Las técnicas de productividad que conozco como pomodoro o GTD se basan en hacer una cosa a la vez para mejorar la productividad. Así que tiene sentido el hacer diseño o solución del problema pero no las dos a la vez.

Además, si vemos que después de terminar tenemos dudas del diseño el hacer cambios en el código nos va a resultar más seguro y fácil porque tenemos un conjunto de tests que nos van a dar seguridad que no estamos rompiendo nada.

 

Resumiendo, que podamos preocuparnos solo por solucionar el problema entre manos o por el diseño pero no los dos a la vez es una de las grandes ventajas de TDD. Además, debido a que tenemos un buen número de test unitarios podemos hacer cambios posteriores en el código con seguridad.