En la retrospectiva de esta semana hemos hablado sobre todo del proceso de desarrollo. Nuestro proceso se apoya en kanban, no hacemos scrum. Scrum es demasiado lento para la velocidad con que nos entran peticiones de cambio de funcionalidad. Nuestros sprints son de una semana y el objetivo es la entrega constante.
Lo que ha sucedido esta semana es que las tareas terminadas se han acumulado a las de sprints anteriores y hemos perdido la información de qué funcionalidades se estaban entregando. La solución que se nos ocurre es que la persona que recoge las incidencias y se encarga de notificar a los clientes de su resolución y de nuevas funcionalidades, esté presente en las reuniones
diarias (daily stand up meeting). Además las tarjetas del kanban estarán tambien en nuestro trac, cuando coincidan con historias de usuario (hay tarjetas más pequeñas que una historia de usuario). Intentaremos que todo el mundo conozca el estado de una funcionalidad desde que se escribe la historia de usuario hasta que se notifica al usuario su puesta en producción. Para ello, todo el mundo es responsable de ayudar a definir bien las historias de usuario, si van a entrar en el WIP (work in progress) y nuestro dueño de producto no ha tenido tiempo de estudiarlas a fondo. Cada uno se reponsabiliza al coger una tarjeta para implementar, de que se finaliza, de que no se queda nada atrás y también de que se avisa de cuándo está subida a producción.
Esta semana toca hacer pruebas de carga de nuestros sistemas para estar seguros de la cantidad de conexiones que podemos aguantar con la puesta en marcha de nuestro nuevo producto. El objetivo de las pruebas de carga no es lanzar muchas peticiones contra el servidor y ver que aguanta, sino hacerle peticiones hasta que se caiga, y entonces tener la medida más precisa posible de hasta cuánto aguanta. Lo contrario sería un falso positivo.
Unfortunately coding for performance tuning leads to code that is hard to understand and maintain.
If I don't write a test, a specification that clearly states what I expect the code to do and see it pass, I can't bet that it will work just by looking at the production code. It would feel like gambling.
"if (userExists === true)".
I used to write desktop applications using Delphi, pyGTK and Windows Forms at the beginning of the past decade. When the web started getting mainstream, it was sad to say goodbye to all the best practices learned all those years. Used to the power of event oriented programming, rich components, data binding, and design patterns in general, developing for the web felt a step back. During the past decade there have been many attemps to mimic the old desktop in the web; portlets, asp webforms, and so on. None of them made developers happy, so the Model-View-Controller (MVC) pattern came to the rescue. However, dealing with the UI is still something developer don't really use to enjoy. DOM manipulation has been a pain in the ass with every browser having different behavior and API. I've been trying to avoid it until now and, to be honest, I am happy to not have invested my time fighting with problems that jQuery handles for me nowdays.
Now, ECMAScript 5 is supported in all major browsers. jQuery and other frameworks make life easier. And there is something that we didn't have in the old desktop programming: the chance to programmatically interact with widgets (UI controls or components). Well there are some frameworks for that in the native desktop, by they came late. This means that we can write automated tests for UI behavior!
So now, we have the chance again to use event driven programming, to really implement patterns like the "observer" and many others. And we can test drive all of them!
We can develop semantic components that add domain knowledge inside UI widgets and make the user experience way better. There is no need for intrusive frameworks that tell us exactly all the layers to be used and how. Everything is ready to craft the code to make it express as much human knowledge as possible.
So we are taking the chance.
Este post de retrospectiva vale por las últimas semanas. Desde el último post de retrospectiva hasta ahora, estamos notando una evolución espectacular en el equipo, tanto en el compromiso que cada uno demuestra escribiendo código de calidad como en la responsabilidad de completar las releases semanales. En la pizarra que usamos en la última reunión de retrospectiva aparecieron más anotaciones positivas que anotaciones de mejora 🙂 Sin embargo en este post voy a resaltar lo que queremos lograr.
La cuestión es no parar aquí porque sigue quedando muchisimo camino por recorrer. Simplemente seguir trabajando duro con ayuda de esta sensación de progreso que va calando en el equipo.
Lo que queremos hacer:
The new version of mockito comes with a new method: spy. Very useful feature but... bad name!
The mockito's "mock" method creates already a spy object. The "spy" method creates a "proxy" or "proxy spy" object. Totally confusing, isn't it?
The "mock" method is not really awful, because you can also use the double as a mock or just a stub, and it is common to use the name "mock" for all kind of doubles, although still confusing. The benefit from naming the double properly is that it helps programming by intention, which is a big part of Test Driven Development.
I would rename "mock" to "double" and "spy" to "proxy". Anyway, don't forget that, when using the mockito's "spy" method any single call that you don't explicitly stub, will reach the actual object. It is really useful to work with legacy code, in fact, we implemented it in pyDoubles, but using the method "proxy_spy".
Just make sure you understand what kind of test double you use and why. That is what matters in the end 🙂