En este nuevo año, estoy participando en la creación de una aplicación, en un equipo ágil, usando un Scrum-like (iteration reviews, planning, standups, iteration backlog, etc..). Tecnologías: .NET, C#, ASP.NET MVC, Azure, SQL Server, y más (en cualquier momento aparece JSON, REST, Javascript, jQuery, algún NoSQL, cache en memoria, etc…). Pero lo interesante de esta aplicación es que ha nacido prácticamente como “green field”. Si bien el proyecto completo tiene casi un año de existencia (y hasta tiene proyectos antecedentes que se remontan a 3 años atrás), la aplicación que le ha tocado a mi equipo es nueva: nace desde un File, New Project.
El proyecto es privado, así que no hay repositorio público para mostrar avance. Pero quería comentar en este post algunas de las estrategias que estamos usando para avanzar en el proyecto.
Primero: buscar basarnos en casos de uso. Anteriormente, el proyecto se basó demasiado (en mi parecer) en solucionar temas técnicos, sin llegar a hacer pie en lo que realmente se necesita. Entonces, desde la primera iteración (son semanales) nos concentramos en mostrar algo que funcione. Si bien hay varios riesgos técnicos a tomar en cuenta, no fueron (todavía) el centro de atención. Nos parece que para el cliente final lo mejor AHORA es mostrar algo andando, para que pueda explorar si es lo que necesita.
Veamos un ejemplo de estrategia: en vez de modelar el dominio con persistencia en la base de datos, lo principal del mismo ESTA EN MEMORIA, en objetos que solamente viven en memoria: persistencia, concurrencia, transacciones no están en la agenda actual, porque por las características del sistema (disculpen no dar más detalles, es privado) NO SON EL TEMA a tratar AHORA. Es mejor explorar una base de solución ahora, que tener todas las piezas en su lugar.
Como el cambio es constante (al aparecer nuevas historias, al reflexionar el cliente final sobre cómo quiere que quede el producto final, sus casos de uso), todo se ha ido construyendo con TDD (Test-Driven Development). El Code Coverage es > 85%, en general (incluido los controladores de vistas web, estamos usando ASP.NET MVC). Cuando hubo que cambiar algo en la segunda iteración (un refactor de los que yo llamo “quirúrgico”) todo esta en su lugar para que los tests nos ayudaran a comprobar que al cambiar la implementación interna todo siguiera funcionando como se esperaba.
Otro ejemplo: esta semana pasada, gran parte del dominio paso a estar persistida en SQL Server (y en Azure SQL Server). El lunes completamos la implementación de almacenamiento/persistencia en esa tecnología, usando TDD, luego la inyectamos en los lugares apropiados, y prácticamente no se rompió ningún test. En la entrega del viernes, tenemos parte del dominio en memoria (para hacer cambios rápidos) y parte en SQL Server (para ir explorando algo más cercano al producto final). Pero estamos preparados para cambiar esa persistencia a Azure Table Storage, si hace falta, y por qué no, al nuevo DynamoDB de Amazon. El desarrollo ágil y TDD nos da el “courage” (coraje) de abrazar el cambio.
TDD, en vez de ser un gasto de tiempo, es un gran avance: primero, nos sirve en el diseño de lo que implementamos. Luego, nos sirve en ir armando algo sin gastar tiempo en pruebas manuales o sesiones de depuración. Vamos avanzando de a “baby steps” (pasos de bebé): cada nueva característica se agrega con TDD, y la vamos integrando. Desplegamos en Azure más de una vez al día, para que el cliente final pueda ir viendo los avances. Las nuevas características se van anunciando en la lista del proyecto.
Otro ejemplo: el jueves se comenzó a implementar temas de seguridad (autorización en particular, con usuarios y grupos). ¿Acaso implementamos eso usando alguna tecnología? ¿Fuimos e instalamos Azman o cualquier otra cosa? ¿Fuimos a usar Access Control System, tokens y claims? No. Armamos los tests e implementamos la lógica (permisos, reglas) en memoria. El viernes ya estaba listo para la demostración, con distintos usuarios (de nuevo, definidos en memoria). De ahora en más, podemos tener retroalimentación del cliente y usuarios finales, sobre qué es lo que funciona o no del “approach” que adoptamos. Sabemos que alguna parte de la implementación puede sufrir en escalabilidad. Es parte de lo que tenemos en el radar. Pero, como digo, “no cruzar el puente antes de llegar al puente”. No es (en este proyecto en particular, cada uno de Uds. analizará su caso y contexto) lo PRIORITARIO ahora. En vez de estar semanas viendo cómo implementar eso con Azman, o con claims, o lo que sea, ya en dos días tenemos algo funcionando, listo para refactorizar a tecnología PORQUE TENEMOS los tests.
Claro que no todo tiene que ser un lecho de rosas. Pero, por lo menos yo, estoy muy contento y entusiasmado por este camino que tomamos. Espero que todo esto permita llevar a buen puerto un proyecto que ya lleva muchos meses dando vueltas.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez