Desarrollo Ágil & Test Driven Development

Voy a comentar algunas cosas chulas que he ido oyendo por ahí sobre el Desarrollo Ágil y el Test Driven Development. Un compañero, Alberto Rodríguez de Lema, dió una charla un día sobre este tema y tenía apuntadas algunas cosillas que creo que está bien comentar con vosotros.

Desarrollo Ágil

Aunque muchos de nosotros estaremos involucrados en desarrollos ágiles, utilizando Scrum o algún híbrido estoy seguro que no lo aplicamos al 100% como deberíamos. Me sorprendió mucho las recomendaciones que nos dió Alberto basada en su experiencia.

Una de las pegas del bodyshopping en España es el rango de tiempo en el que se deben desarrollar las aplicaciones. La calidad se ve afectada siempre por los tiempos, y los empleados somos incapaces de absorber técnicas que nos faciliten la vida y nos hagan ser más productivos. Normalmente tienes que dedicar tu tiempo libre a mejorar como profesional ya que la formación escasea. El problema además es que te acaban viendo como un enemigo, que no tienes ni idea de lo que haces porque las cosas no funcionan o no van lo suficientemente rápido. Muy lamentable pero real.

A continuación veremos algunas técnicas poco utilizadas por regla general pero que se utilizan en entornos especializados de desarrollo software y por lo tanto a algunos le sonará a chino o incluso lo verán una gilipollez (basado en hechos reales).

Pair Programming

Siempre que explico esto y que me gustaría utilizarlo me dicen: "es poco productivo". Parece ser que todavía seguimos empeñados en ver el desarrollo de software como si nos pusieramos a picar en una mina. El desarrollo de software es un ejercicio intelectual, para llegar a soluciones necesitamos atacar estos problemas de manera distinta.

Pair Programming consiste en juntar a dos personas con distinto nivel o conocimientos y ponerlas a desarrollar software. Para ello se utiliza normalmente la técnica Ping-Pong TDD, en la que una persona codifica y arregla fallos mientras la otra plantea pruebas. En pair programming se recomienda cambiar de pareja y en concreto Alberto nos dijo que lo hacían cada 2-3 días. Esto tiene pros y contras:

Las cosas buenas es que las personas del equipo si que eran realmente Multidisciplinares.

Las cosas malas es que las personas acababan medio locas por el cambio de contexto.

Integración continua

Las prisas hacen que no nos paremos a pensar pero ¿qué pasa si los cambios los ponemos en producción directamente habiendo hecho simplemente unit test? Seguramente petará. Poco o nada dedicamos a la integración continua y debería ser tan necesaria como un buen gestor de repositorios.

Alberto nos comentó que tenían una alarma que sonaba en toda la oficina cuando alguien subía algo y fallaba.

El perfil DevOps

Si tienes el privilegio de tener a una persona sólo de sistemas dentro de tu proyecto (cosa rara), verás que sufre algunos ataques al corazón de vez en cuando cuando tiene que trabajar en su día a día. Para ayudarle a que no tenga estos problemas, es recomendable que aprenda a como optimizar su trabajo utilizando técnicas de programación.

Test Driven Development

Los principios básicos de Test Driven Development son:

· Escribir nuevo código si tenemos primero un test que falla.

· Eliminar duplicación (conseguir un código lo más "bonito" posible)

Esto tiene unas implicaciones técnicas:

· Diseñar el código según escribimos nuestros tests: debemos encontrar un balance entre el diseño de UMLs y la realización de tests para que nos orienten por donde tenemos que ir.

· El entorno de desarrollo tiene que ser capaz de decirnos rápidamente el estado de nuestro código en todo momento (debe ser rápido o sino se deja de hacer pruebas, por lo que hay que diseñarlos para q sean lo más rápido posibles)

· Diseñar componentes altamente cohesivos y muy poco acoplados para conseguir probarlos fácilmente.

Ciclo de desarrollo en TDD

RED->GREEN->REFACTOR

· El objetivo es pintar el verde (según Alberto, en su equipo no te podías ir al baño si tenías un test en rojo XD). Digamos que hay que intentar que los tests siempre pasen a verde y no estén en rojo, después de eso puedes continuar.

· Esto conlleva una serie de ventajas:
- Cada pocos segundos se comprueba que el código hace lo que debería. Si algo va mal sólo hay unas pocas líneas de código que comprobar.
- Escribir test antes que el código nos centramos en interfaces más que en la implementación.
- Los tests se suben al repositorio con el código->se genera la documentación->luego cada programador ejecuta los tests en cada build.

Y hasta aquí el deleite. Aprendí mucho en esa sesión, pero lamentablemente no puedo poner en práctica estas cosas, ya que o el equipo no está institucionalizado o todo es con prisas y SIN formación. Como siempre digo, hay muchos más aspectos a destacar y por ello te animo a que comentes que crees que puede ser de utilidad a los equipos de desarrollo ágiles.

Nos vemos en la siguiente.