En esta cuarta parte del libro Nat y Steve nos cuentan que el código de los tests debe ser cuidado tanto como el código de producción. A lo largo de este post voy a resumir solo la parte de «Escuchando a los tests» ya que creo que se merece dedicarle un post entero.
Normalmente, cuando encontramos una nueva funcionalidad que es difícil de testear existe una razón detrás de ello. Si aprendemos a escuchar a los tests conseguiremos simplificarlos y a su vez mejorar el diseño de nuestra aplicación.
Hace unos días di una charla sobre pair programming para el equipo, no es que yo sea un experto en la materia, pero lo que estaba claro es que no lo estábamos haciendo de forma adecuada.
¿Por qué no lo hacíamos bien? Creo que fallábamos cuando un miembro de la pareja, sin darse cuenta, monopolizaba el teclado. Otro aspecto que debíamos mejorar es que los programadores con más experiencia intentábamos imponer nuestras ideas en lugar de llegar a un acuerdo con la pareja.
Basándome en algunos recursos¹ que encontré en internet y en el libro Pair Programming Illuminated, hice una pequeña presentación y discutimos sobre como estábamos haciendo pair programming y como podríamos mejorar nuestra técnica.
Uno de los aspectos que acordamos mejorar es el rol del navegador. Es fundamental que la persona que está navegando ayude basándose en abstracciones al que tiene el teclado en ese momento. Por ejemplo, es mejor comunicar «vamos a crear un componente que sirva para la selección de usuarios», que decir «ahora extendemos una clase de react que contenga un select al cual le vamos a pasar un array con los usuarios».
Otro aspecto a mejorar por los desarrolladores más experimentados es limpiar la mente de prejuicios y experiencia pasada, ya que de esta manera podemos aprender nuevas técnicas de la persona con la que estamos programando.
Una de las conversaciones que surgieron es que programar por parejas nos está ayudando a mejorar la comunicación entre los miembros del equipo. Además, en mi caso, me está ayudando mucho a practicar inglés y a conocer mejor el business de los productos.
Happy coding and pair programming!
En la Software Craftsmanship de Pamplona, Daniel Ojeda (@SuuiGD) propuso hacer la kata RPG Combat Kata, en ese mismo momento no la hice pero me quedé con ganas de hacerla.
En estos días de vacaciones la he hecho y me ha parecido muy enriquecedora ya que tienes que cuidar mucho el diseño en la fase de refactorización, ya que si no lo haces de esta manera en la próxima iteración tendrás muchos problemas para poder añadir las nuevas features propuestas.
A mi me ha pasado factura el no refactorizar lo suficiente en la iteración 4, ya que he tenido que hacer alguna «chapuza» para poder implementar la iteración 5.
Os dejo el enlace con el código con el código.
Recientemente, he tenido el placer de asistir a un curso de Continuous Delivery impartido por Néstor Salceda y la gente de GeeksHubs Academy y de leer un par de libros, Building Microservices, de Sam Newman y Continuous Delivery with Windows and .NET de Chris O’Dell y Matthew Skelton. Todo esto me ha ayudado a descubrir una serie de prácticas y herramientas con las que conseguir automatizar los procesos rutinarios que hacemos todos los días.
Para entregar valor de forma continuada, sin estrés y a un ritmo sostenible en un proyecto de software es fundamental no gastar tiempo haciendo tareas repetitivas que no aportan valor. En mi opinión, una de las claves para conseguir el objetivo es automatizar procesos y crear una cultura de la automatización dónde nos tendríamos que preguntar si merece la pena automatizar una tarea y si el retorno de la inversión pagará el coste de la automatización.
Hace unos días asistí a la Conferencia Agile Spain 2015 que se celebraba en Madrid en el Círculo de Bellas Artes. Un lugar estupendo en el centro de la ciudad. Ésta ha sido la tercera edición a la que asisto, después de Bilbao 2013 y Barcelona 2014.
La mayoría de las charlas a las que asistí en la conferencia fueron del track «Mejorando software» y me gustaría compartir algunas impresiones sobre ello.
El camino de un aprendiz 