Decisiones de repositorio y workspace en TFS/VSO

Antes cuando desarrollabas SW y se te planteaba el versionar tu código fuente algunos no tenían idea de lo que se hablaba, y en el otro extremo solo había dos opciones ampliamente usadas: SourceSafe y CVS, aparte claro de opciones chapuceras como: diskettes, carpetas fechadas compartidas y USB.

Ahora mucha agua ha corrido bajo los puentes, así que el que no versiona SW es porque ha vivido aislado de la realidad, o porque de alguna manera no ve la justificación económica de ello (hace poco me comentaron que una entidad crediticia sigue manejando sus desarrollos con carpetas fechadas y comprimidas y recién iban a analizar la viabilidad de usar SVN), por lo que el problema en estos momentos es decidir que repositorio usar y las implicancias de su decisión.

En este momento me pueden decir “¡Pero tu usas TFS, ya no tienes que decidir!”, pues la verdad que no, hasta el 2010 no había que tomar muchas decisiones, pero en el momento actual también toca decidir como es que vamos a usar TFS, entonces.. vamos a ello, repasemos el escenario.

En este momento al crear un proyecto en TFS/VSO tenemos dos opciones de mecanismo de control de versiones:
 

TFVC: El mecanismo tradicional de TFS de toda la vida, heredando terminología de SourceSafe como “check-in” “check-out”, pero mucho mas potente, todo almacenado en SQL Server, permitiendo gestión de branches y merges, aparte claro esta de la integración de tus changesets con una actividad determinada. Su modelo es Centralizado al igual que Subversión por ejemplo, con todas las implicancias que eso trae, que no vamos a discutir ahora.

Lo curioso es que si optamos por usar esta modalidad hay que tener en cuenta un detalle adicional: el tipo de Workspace ya que hasta TFS 2010 solo había el workspace en servidor, vale decir que el servidor de TFS llevaba un seguimiento de cual es el estado de cada una de las maquinas que se conectaban al repositorio, lo cual debemos reconocer no funcionaba muy bien, llegando al extremo de que en algún momento el usuario sabia que no estaba sincronizado, pero el servidor insistía en que no tu workspace esta bien, y arreglar eso, complicado.

Con los workspace locales, esos problemas ya no existen, aparte de que proveen una mayor flexibilidad para trabajar sin problemas cuando el servidor esta desconectado, pero de eso nos cuenta con mas detalle El Bruno, solo debo añadir que si se opta por TFVC solo hay un escenario en el cual tendría sentido usar workspace en el servidor: cuando tu IDE aun es VS 2010 o anterior, en cualquier caso es workspace locales, ahh la decisión se hace en el IDE no en el servidor.

Git: ya hemos hablado anteriormente de este recién llegado a las plataformas Microsoft, y creo sinceramente que debemos probarlo, intentar usarlo en nuestros proyectos, pues los DVCS han llegado para quedarse y Git ya es casi el estandar de facto, proveyendo muchas ventajas; dicho esto debemos ser conscientes que a la fecha (si alguien lee esto 2 años despues puede que se ria), si bien Microsoft ha integrado totalmente el “protocolo” backend de Git en sus productos aun no ha terminado de pulirlo en cuanto a interfaz (quiero creer que la próxima versión de VS tendrá una interfaz para Git que rivalice con SourceTree) y que de momento no podemos usar una herramienta tan potente como los Code Review integrados, a los cuales me acostumbre rápidamente cuando use por primera vez TFS 2012, ni tampoco los Gated Check in a la hora de hacer Integración continua (en breve: esta modalidad permite que un cambio no se añade al repositorio si la Build falla).

Conclusión: si no tienes una demanda muy fuerte de hacer uso de CodeReview o Gated Check In, usa Git, pero de la mano ve aprendiendo los comandos aun no disponibles desde el IDE, pues seran necesarios para sacarle el jugo. En otro caso (el Code Review si que puede ser un deal breaker en muchos casos) no temer y usar los workspace locales con TFVC.

A ver cual es la situación de aquí a un año, probablemente nuestro flujo cambie para entonces.

Kanban in Action de Hammarberg y Sundén

Durante el año pasado tuve la oportunidad de ser revisor de el libro de Marcus Hammarberg y Joakim Sundén: Kanban in Action.

Fue una gran oportunidad el poder ver los borradores del libro, y desde el inicio me engancho con su enfoque, un primer capitulo destinado a demostrar como es posible (mediante la ayuda del equipo ficticio Kanbaneros), partiendo de la situación actual, implementar un flujo de Kanban en tu organización o proyecto de manera sencilla.

El resto del libro nos ayuda a ir comprendiendo la teoría detrás de Kanban (metricas, clases de servicio, planificación, etc), el porque es bueno tener controlado el Work In Process, recomendaciones y alternativas para cuando nos encontremos con situaciones particulares (una emergencia que debe ser solucionada de inmediato, por ejemplo), de una manera muy clara. Para lograr esto en todo momento los diversos Kanbaneros aparecerán con preguntas y conversaciones para clarificar los puntos.

Definitivamente recomiendo la lectura de este libro, pues como digo en mi comentario en la contraportada es “A practical way to start with kanban … and learn the theory along the way”, lo unico que lamento del libro es que al final no se incluyo el capitulo de Scrumban o el detenerse un poco mas en utilizar Kanban en procesos iterativos como.. si.. Scrum.

Pues nada, si quieren tener una buena introducción a como empezar a usar Kanban les recomiendo leer el capitulo 1. Ademas nuestros amigos de Manning nos estan regalando el capitulo 13, con diversos juegos para aprender Kanban de manera divertida.

TDD: ¿El emperador esta desnudo?

Desde hace dos semanas ha causado cierto revuelo en las comunidades de desarrollo este articulo de David Heinemeier Hansson, creador de Ruby on Rails, donde básicamente apunta que él seguirá usando Unit Test pero que TDD (entendido como programar los tests antes de codificar) ya esta muerto y que no tiene beneficios, de ahi me quedo con esta porción:

The current fanatical TDD experience leads to a primary focus on the unit tests, because those are the tests capable of driving the code design (the original justification for test-first).
I don’t think that’s healthy. Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that’s “slow”. Like hitting the database. Or file IO. Or going through the browser to test the whole system. It’s given birth to some truly horrendous monstrosities of architecture. A dense jungle of service objects, command patterns, and worse.

Y si, se podría decir que había mucho de fanatismo en esto, expresiones como “código legado es código sin tests”, “WebForms es malo pues pues no deja testear”, “elabora una arquitectura evolutiva basada en tus tests” y similares estaban a la orden del día en blogs y conferencias, de hecho cuando publique este post sobre si los nuevos patrones (inducidos por TDD) ayudaban o no a la legibilidad del código un guru dijo que yo había “missed the point”.

No se me entienda mal, yo creo que los tests son necesarios y salvadores de tiempo… en algunas circunstancias, por ejemplo hace un tiempo vi a un QA probar una aplicación que calculaba ciertos valores, para hacer esto iba a su Excel, copiaba los parámetros en la aplicación, y si la aplicación devolvía el valor esperado que estaba anotado en el Excel, estaba Ok, y claro, como es usual si la aplicación era actualizada, estos tests deberían ejecutarse de nuevo para verificar que no hubiera una regresión, este es un caso muy evidente como batería de Unit Test con diversas combinaciones de valores ayudaría a reducir los tiempos de prueba, garantizando la calidad de la aplicación en cuestión, como siempre digo, ¡si en una aplicación de cálculos matemáticos o financieros no le metes Unit Test no te puedes fiar de la calidad para nada!.

Personalmente creo que en este caso opero mucho el “principio de autoridad”, eran pocas las voces quienes cuestionaban de que el modelo de TDD (y la compleja arquitectura a la que podria derivar) sea totalmente valido, y era necesario que alguien con cierto peso dijera “el emperador esta desnudo”.

Como era de esperar, algunas respetadas voces han respondido al manifiesto de DHH, destacando Robert Martin con este articulo, y luego un debate online entre DHH, muy interesante.

Creo que el debate continuara un buen rato, pero lo bueno es que ha permitido que quienes teníamos reparos al fundamentalismo del TDD podamos salir de nuestros agujeros sin ser abucheados.