La primera razón es bastante trivial, si haces BDD entonces tienes un enfoque “test first”, es decir, escribes el test antes que la implementación, y no se escribe ni una sola línea de código hasta que no tienes una especificación (test) en rojo. En este sentido es completamente imposible usar el paradigma de grabar navegaciones para automatizar el testing, ya que tienes que tener el test automatizado antes que la implementación y por lo tanto no puedes grabar nada.

La segunda razón tiene que ver con el mantenimiento. Si decidimos que el test de cada escenario de una historia de usuario se va a automatizar grabando una navegación, entonces lo que estamos testeando realmente es la UI y no la funcionalidad propiamente dicha. Cada vez que se produzca un cambio trivial en la UI de una página o panel, vamos a tener que grabar de nuevo todas las navegaciones que usen ese panel o página, aunque la funcionalidad no haya cambiado realmente. Claramente al usar el paradigma de “grabar navegación” estamos acoplando nuestros tests al diseño fino de la interfaz de usuario, que como todos sabemos, cambia con más frecuencia que la funcionalidad propiamente dicha de la aplicación. Un simple cambio en el atributo “name” o “id” de un elemento, o eliminar un botón de “buscar” para hacer una búsqueda en tiempo real, nos va a estropear las navegaciones.

Ojo, también nos podemos meter en este lío haciendo BDD, con por ejemplo Cucumber, si no tenemos cuidado. Pero mi argumento es que si usamos una herramienta que graba navegaciones como base de nuestra estrategia de testing funcional, este problema es inevitable. Por el contrario si decidimos usar un enfoque basado en programar nuestros tests podemos evitarlo fácilmente. ¿Cómo? Simplemente usando el patrón “page object”, e implementar cada “page object” con algún framework de automatización de UI, como WebDriver de Selenium o Watir. De esta forma si se produce un cambio en una UI, que no altere la funcionalidad, entonces sólo necesitamos retocar el “page object” correspondiente, sin necesidad de modificar nada en nuestros tests, escenarios y steps.

El que nuestros tests sean código hecho por nosotros es bueno. Podemos aplicar todas las técnicas de ingeniería del software que conocemos y aumentar la mantenibilidad de nuestros tests. Eso es, recordad que el código de test tiene que ser mantenible, y todo el tema de legibilidad, DRY y SOLID se le aplica, y por lo tanto podemos usar toda nuestra habilidad para que esto se cumpla.

Bien, y esto es todo, ¡ no diréis después que mis posts son muy largos !

P.S. Sois programadores, ¡ que no os asuste programar ! ¡ No os escondais en herramientas !

• Esta CAS2011 me ha gustado más que la del año pasado. Desde mi punto de vista la organización ha mejorado y ha habido más caras nuevas.
• Nos estamos mirando el ombligo.

Algunos pensareis que las hackatones son situaciones especiales donde no se aplican las reglas normales del desarrollo de software. Como tenemos poco tiempo sólo puedes ponerte a codificar como pollo sin cabeza, echar jornadas maratonianas y beber mucho red bull… ¡ nada más lejos de la verdad ! Este tipo de concursos representan muy bien la mayoría de los proyectos que te vas a encontrar en el día a día normal. Veamos… tiempo y recursos insuficientes, lista de requisitos a todas luces excesiva, problemas de última hora, contratiempos, pánico y la sensación de no llegar a producción, o sea, ¡ el verdadero “mundo real” ! Por lo tanto si al participar en una hackaton dejas de lado la disciplina de trabajo, entonces es probable que en un proyecto de verdad también abandones la disciplina. Por eso, cuando me presenté me dije: “esto hay que hacerlo con TDD y entrega continua de valor a muerte” Je, je, que iluso. Veamos que pasó.

El primer día empezamos bien, nos reunimos y nos pusimos de acuerdo en la funcionalidad, hicimos una maqueta papel, y nos pusimos manos a la obra. El compañero @etnassoft decidió hacer una maqueta HTML y @pasku1 y yo nos pusimos a hacer BDD. Todo bien, ¿no? ¡ Mal ! Esa fue la raíz de todos los problemas. Si vas a hacer entrega continua de valor, no puedes dividirte en equipos de especialistas, todos tienen que trabajar en equipo para sacar lo más rápidamente posible cada historia de usuario. Lo que terminó ocurriendo, de forma inconsciente, es que la UI se desarrolló por completo, para todas las historias de usuario. Igualmente, el servidor se desarrolló por separado para todas las historias de usuario. Lo curioso de esto, es que fue un fenómeno totalmente subconsciente, fruto de separarnos “temporalmente”. En el fragor de la batalla nos olvidamos de que teníamos que centrarnos en historias y no en capas. Cierto, cada capa se desarrolló por historias, pero no integramos hasta que estuvieron todas las historias hechas en cada componente, ¡demasiado tarde!

En un enfoque orientado a la entrega continua de valor, hubiéramos integrado la UI y el servidor por cada historia. Los problemas los hubiéramos detectado al principio, cuando es más fácil, al ser la aplicación pequeña, y encontrarnos más descansados. Además de ser más eficientes hubiéramos eliminado el factor pánico, al tener al menos algunas historias (las más importantes) listas para producción.

¿Hicimos TDD? ¡ Sí ! ¿De que sirvió? De poco. Nuestra capa de “negocio” quedó cubierta por bastantes tests, ¡ pero ninguna capa de negocio sirve sino está conectada a una UI ! Esto debe servir de lección a los que piensen que sólo con prácticas de ingeniería y usar tecnologías y frameworks puedes llegar al éxito de tu proyecto. Tus prácticas de ingeniería deben usarse en el contexto de unas buenas prácticas de gestión de proyectos, y viceversa. Todas las prácticas se apoyan e interactúan unas con otras y están pensadas para cubrir las debilidades de las demás.

Durante el transcurso de la hackaton ocurrieron los consabidos e inevitables imprevistos de todos los proyectos (lo dicho, igualito que el mundo real). A saber:

• Se cayó el github. ¡Nooooo!
• Twitter tuvo un bajón de rendimiento. Todas las peticiones tardaban al menos 30 seg. Eso hizo que nuestro ciclo de pruebas integradas fuera impracticable. Ayer probé y la respuesta era instantánea.
• Un espacio en una cadena de texto de una configuración nos estuvo fastidiando durante 4 horas hasta que nos dimos cuenta.
• Los drivers de node.js para MongoDB fueron un dolor.
• Heroku no quería arrancar…. (¿qué demonios le pasó a la nube ese fin de semana?)
• Un troll se coló por twitter y nos desconcertó bastante. Sí, es cierto, cosas que pasan.

P.S.S. Enhorabuena a los organizadores, ¡en especial a @VictorSanchez!

Desde hace dos años empecé a sentir que existe otra forma de trabajar posible, basado en los conceptos de desarrollo Agile y Lean. Desgraciadamente para mi, la reciente crisis ha hecho que tal forma de trabajo sea imposible de implantar en atSistemas de forma simple y sin poner en peligro a la empresa (que ofrece actualmente bastante más de 350 puestos de empleo). Me marcho manteniendo relaciones cordiales con mi antigua empresa y espero seguir colaborando con ellos en cualquier proyecto agile que les surja.

Reconociendo este hecho, decidí abandonar atSistemas e intentar demostrar que se puede ganar dinero trabajando de forma ágil, y anteponiendo la calidad a la tarifa. De esta forma podré llevar a cabo mis ideas con mi propio dinero y bajo mi propia cuenta y riesgo. El intentar encontrar y explotar mercado para esta filosofía de trabajo es un objetivo personal que pienso perseguir con mucha energía. Si os digo la verdad, ahora me encuentro muy ilusionado y lleno de fuerza. Sólo el tiempo dirá si he apostado por caballo ganador, pero yo tengo fe en mi. Es la misma confianza que hizo que me marchara de Sevilla a Madrid a trabajar en una empresa que en aquel entonces no conocía de nada, a una ciudad desconocida, sin experiencia laboral, con el dinero justo para vivir un mes y habiéndome leído por primera vez lo que era una JSP en el AVE. Yo diría que aquella fue una decisión acertada, y no veo por que ésta no puede serlo.

Ahora quiero despedirme de toda la gente con la que he trabajado en atSistemas; toda la gente que me despidió el viernes y me hizo saltar una lagrimita cuando no miraban; despedirme de los chic@s de Cádiz, mis “conejillos de indias”, con los que experimenté con el agilismo y mis malditos “frameworks de la muerte” (aun me queda algo de aquella botella de serie limitada); despedirme de los compañeros de Barcelona (Aleix, tenemos que vernos); despedirme de “mis” arquitectos, espero que sigáis defendiendo el fuerte, y también de las chicas de administración y de RRHH. También me despido de los comerciales (sí, también de vosotros) a los que les di la brasa con mis ideas. Aunque espero que no sea una despedida absoluta, sino que nos vayamos viendo de vez en cuando (y Lourdes, espero mandarte alguna factura de vez de en cuando ).

Tengo que dar también las gracias a gente que no es parte de atSistemas por ayudarme y apoyarme, me refiero como no, a la comunidad ágil en España, que además me ayudaron a comprender que no era el único que estaba haciendo “locuras” por ahí. El encontrar esta comunidad ha sido algo muy importante para mi, y me ha animado a salir de la “cueva”. Me sorprendí de sus “retuits” y mensajes de ánimo cuando anuncié mi nueva etapa personal y profesional. Me resultó revelador que me dierais enhorabuenas más que ánimos :-O.

Y por supuesto un beso a mi mujer, @mcberros, que me ha dado soporte incondicional en esta arriesgada (y emocionante) decisión.

Y aquí os dejo un par de fotos. En la primera están muchos, pero faltan muchos más, que están distribuidos por todas partes de España:

Y aquí la otra foto, donde se atestigua por qué no me sentía parte de atSistemas…

…porque obviamente soy el más feo de la oficina

Saludos a todos y espero que podamos hacer una quedada.

P.S. Y por supuesto gracias por el iPad2, ¡ que era lo que me faltaba para convertirme en un apple fan boy !

P.S.S. No puede faltar la foto de la botella edición limitada:

1. No estimes si no lo necesitas. Normalmente se estima para adelantar una previsión a los interesados en el proyecto y para evaluar si algo se debe implementar o no.
2. Sólo debe estimar personal experto, que haya construido software similar en el pasado.
3. Estima por comparación, y no usando unidades absolutas.
4. No compares cosas dispares, tanto en tamaño como en nivel de abstracción. Por ejemplo, tareas con historias de usuario, o historias de usuario con releases.
5. No necesitas estimar tareas.

La regla número 2 nos la dice explícitamente Scrum: el PO sólo estima el valor y el equipo de desarrollo estima el coste. Cada uno estima dentro de su área de conocimiento. Ninguna de las partes debe admitir presiones por parte de la otra para que cambie su estimación. Se asume un equipo experto, si algún miembro es un junior, yo recomiendo no darle mucho peso a su estimación, pero que participe en ella para que vaya cogiendo experiencia.

La forma más sencilla de aplicar la regla número 3 es no permitir usar unidades absolutas, como horas, dinero, etc. Simplemente se coge una funcionalidad a estimar y se pregunta, ¿en qué grado esta funcionalidad es más grande o pequeña que esta otra? ¿En qué grado el cliente valora más esta funcionalidad que aquella otra? A dichas preguntas se debe responder en unidades relativas, por ejemplo, “es el doble”, “es similar”, “es un 123% mayor”, etc.

Si a la regla número 3 le añadimos la 4, obtenemos una escala de medida relativa pero que a la vez está simplificada. Si sólo debemos comparar cosas que sean similares, ¿tiene sentido decir que esta funcionalidad es 100 veces más grande que esta otra? No. Claramente las dos cosas que estamos comparando no se encuentran al mismo nivel. Otro problema es intentar obtener una precisión en la estimación absurda, similar o incluso mayor a nuestro margen de error. No es razonable estimar que tal funcionalidad es 1.07 veces más grande que tal otra, cuando normalmente nuestro margen de error es mucho mayor de un 7%. Para reforzar estas ideas se han propuesto varias escalas de medida, y al realizar una estimación no se puede asignar un valor que no aparezca en la escala.

La más famosa de dichas escalas es la escala de Cohn. En la escala de Cohn se admiten los siguientes valores: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Si os fijáis en escalas pequeñas tenemos 0, 1, 2 y 3, admitiendo que podemos tener cierta precisión. A escalas más grandes, 5, 8, 13, 20, 40 y 100, hay huecos. Estos huecos indican que no debemos invertir esfuerzo en ajustar nuestra precisión ya que estaríamos excediendo el margen de error que normalmente tenemos al estimar.

Siguiendo con el razonamiento que defiendo a lo largo de toda esta serie, ¿tiene sentido decir que una funcionalidad es 20 veces mayor que otra? Seguramente no, y estemos comparando funcionalidades en escalas muy distintas de tamaño. Normalmente una funcionalidad mayor que 5 u 8 se etiqueta como épica. De hecho las funcionalidades épicas normalmente no caben en un sprint, y por lo tanto no son aptas para ser implementadas. Si en vez de Scrum usas kanban, tampoco te salvas, ya que si introduces en el sistema funcionalidades de tamaño muy variable, tanto tu tiempo de entrega como tu productividad se van al garete (teoría de colas). Por lo tanto las funcionalidades épicas son carne de analista funcional, no se aceptan en la fase de desarrollo y deben ser analizadas y descompuestas con más rigor.

Lo inverso ocurre con funcionalidades de tamaño 0. En este caso se consideran tan pequeñas que no merece la pena de gastar esfuerzo en estimarlas. Normalmente representan un nivel de abstracción por debajo del que estamos tratando. Podría se una tarea en vez de una funcionalidad, o un simple detalle de ésta. En general cuando tenemos varias cosas de tamaño cero, o bien las descartamos por estar en un nivel de abstracción inadecuado, o bien las fusionamos si están relacionadas entre si.

Si tenemos en cuenta estas dos prácticas, podemos llegar a la conclusión de que la escala de Cohn, aunque útil para principiantes, no es realmente lo que buscamos. Así llegamos a la otra escala que se usa mucho: tallas de camiseta. Los valores admisible son S, M, L y XL. Las funcionalidades XL se consideran épicas. Sólo se aceptarán funcionalidades S, M o L. Este sistema simplifica el proceso de estimación y evita que caigamos en las trampas de estimar en horas o con una precisión irreal. La dificultad de este sistema estriba en que la capacidad del equipo debe medirse también en tallas de camiseta. Por ejemplo: en un sprint el equipo será capaz de 1 funcionalidad L, 2 M y 4 S. Esto puede causar problemas de estilo de “si tenemos 1 funcionalidad L, pero no hemos escogido ninguna que sea M o S, ¿podemos escoger otra funcionalidad L?”.  Una posible solución es definir equivalencias entre tallas: 1 L son 2 M y 6 S, pero 1 M son 2 S.

Otra posible solución para este problema es simplemente no usar una escala. En esta modalidad las funcionalidades o bien son épicas o no lo son. En este caso se deben descomponer todas las funcionalidades de forma que sus tamaños no sólo sean comparables, sino muy similares y constantes.  De esta forma el proceso de estimación se simplifica enormemente, y si se hace bien se reduce la variabilidad de las funcionalidades a implementar. Esto último es especialmente importante, ya una mayor variabilidad implica peores estimaciones y también peor productividad (de nuevo teoría de colas). De esta forma acercamos bastante Kanban a Scrum, donde realmente estaríamos haciendo Kanban si la capacidad de nuestro equipo fuera siempre igual a su límite de WIP. También nos permite estar alineados con la regla 1. La dificultad de esta técnica radica en que tanto el equipo como PO deben ganar mucha experiencia estimando, analizando las funcionalidades y conociendo la capacidad de la otra parte. Por lo tanto sólo lo veo factible en equipos muy maduros.

Finalmente, la regla número 5 simplemente nos indica que tanto al PO como a los stakeholders del proyecto no les interesa saber la descomposición en tareas del proyecto. Si las funcionalidades se descomponen o no en tareas, y si éstas se estiman o no, es una cosa del equipo de desarrollo. Al PO no el interesa el Sprint Burndown, ni el Task Board, sino el Project Burndown, el reporte de bugs y el flujo acumulado de entrega de funcionalidad. Como excepción a esta regla tenemos el caso en el que parte del equipo de desarrollo pertenece al cliente, o que tal vez no hay un equipo sino varios equipos de especialistas que forman un pipeline. Para asegurar una correcta coordinación, puede ser razonable hacer un plan de tareas y llevar un seguimiento de éstas, pero obviamente esta forma de estructurar equipos no es la recomendada en un proyecto gestionado de forma ágil.

Como apunte meramente personal, mi posición con respecto a la estimación es bastante pesimista, ya he visto muchas veces como hasta la estimación más cuidadosa fracasaba, y como planes muy bonitos plantados sobre un “project” se iban al garete en cuanto tenían el más mínimo contacto con la realidad. Mi opinión personal es que hay que estimar en formato “rápido y sucio”, y el proceso de desarrollo que uséis debe estar preparado para trabajar con este tipo de estimaciones aproximadas. Bueno, pues con esto acabo la serie sobre estimación, espero que os haya sido útil.

• Evaluar si es razonable o no presentarse a un proyecto cerrado, y que coste y tiempo podemos ofertar. El problema precisamente  está en que esta evaluación se realiza en el momento de hacer la oferta, que es justo donde tenemos menos información sobre el proyecto, y por tanto, menor precisión en la estimación. Además la estimación deja de ser una estimación y se transforma en un contrato. En este sentido los proyectos cerrados son muy arriesgados. La única circunstancia en la que el riesgo sería aceptable es que el proyecto que se presupuesta sea muy similar a otros que hayamos hecho en el pasado, y que el tamaño de éste no sea muy grande. Aquí lo único que podemos hacer es estimar el tamaño del proyecto en comparación con proyectos pasados. Para ello podemos hacer una captura de requisitos de alto nivel y asumir un entorno tecnológico y arquitectura similar a la de proyectos pasados.
• Release plan. En el release plan nos comprometemos a definir que funcionalidades se pondrán en producción en que momento. La release plan se puede hacer de dos formas: orientada a fecha u orientada a funcionalidad. En la primera las fechas de entrada en producción son críticas y lo que estimamos es cuanta funcionalidad podrá entrar para esa fecha. O sea, tiempo fijo, alcance variable. En la segunda modalidad el alcance es fijo y lo que es variable es el tiempo, intentando estimar cuándo podremos poner en producción un conjunto predefinido de funcionalidad.

Si lo pensáis bien, en ninguna de las dos actividades anteriores es necesario estimar tareas. ¿Por qué? Simplemente porque ni a mi jefe ni a mi cliente le interesa saber cuanto voy a tardar en hacer una tarea. Lo que les interesa realmente es cuando voy a tener disponible tal funcionalidad, release o proyecto y cuanto me va a costar. Algunos diréis, sí, sí, pero es que yo descompongo en tareas, las estimo y después las sumo. Yo os digo que estais gastando dinero inútilmente en analizar una funcionalidad para ver que tareas os salen, y que vuestro margen de error no va a disminuir significativamente con respecto a una estimación directa de la funcionalidad. Dicho esto, ¿cómo estimo entonces una funcionalidad? Como dije en mi anterior post, los seres humanos somos buenos estimando por comparación, por lo tanto lo sensato es comparar la funcionalidad a estimar con otras similares implementadas en circunstancias similares en el pasado. Como veis no es necesario descomponer, ya que a nadie, excepto a nosotros, le importan las tareas, y el método que propongo es más sencillo y barato. Comparar una funcionalidad con otras ya hechas es más simple que hacer un análisis de que tareas se necesitan para realizar la funcionalidad, y después estimar cada tarea por separado.

Existen un par de dificultades en la regla anterior de “no analizar”. La primera es que lo que estemos estimando sea de tamaño “grande”. Según lo explicado en el anterior post, cuanto más grande y a más largo plazo estimemos, peor precisión obtendremos. Podríamos pensar en comparar un proyecto cerrado con otro proyecto cerrado implementado anteriormente, pero normalmente los proyectos son lo suficientemente grandes como para que nuestro error de estimación no sea práctico. Lo mismo se aplica con las releases y los release plan. También puede ocurrir con las funcionalidades que sean especialmente grandes. ¿Qué hacemos? Pues simplemente dividir. Dividir proyectos en releases, dividir releases en funcionalidades y funcionalidades grandes en otras más pequeñas. Dividir hasta que la precisión que podamos alcanzar con cada trozo sea razonable (y no más). Pero, ¿no es lo mismo ésto que el caso anterior de dividir una funcionalidad en tareas? No. Veamos las razones:

• Al cliente le interesan las funcionalidades, no las tareas. El cliente evaluará el resultado final en función de las funcionalidades entregadas. Por lo tanto el plan de proyecto debe expresarse en funcionalidades, y no en tareas, para que el cliente pueda hacer un seguimiento que pueda entender (¿Se nos retrasó esta funcionalidad?¿Cuántas funcionalidades nos quedan?)
• Funcionalidades y tareas están en dos niveles de abstracción diferentes. Podemos dividir un proyecto en releases, y estas en funcionalidades, y las funcionalidades en otras más pequeñas, que no abandonamos el nivel de abstracción que representa el “qué tiene que hacer el sistema”. El realizar estas divisiones y refinamiento de la funcionalidad es en realidad el “análisis funcional”. Las tareas están en otro nivel de abstracción, el “cómo pensamos construir el sistema nosotros”. En este sentido el salto entre funcionalidad y tareas es más brusco y propenso a error, y realmente hacerlo es parte del “diseño técnico”. ¿Queremos empezar a hacer el diseño técnico antes de planificar y estimar?

La otra dificultad se produce cuando no tenemos experiencia previa con algún proyecto o funcionalidad similar, es decir, no existe nada con lo que comparar. En general en esta circunstancia nuestra estimación va a ser muy arriesgada hagamos lo que hagamos. Estaríamos tentado de analizar dicha funcionalidad en tareas, con la esperanza que las tareas que salgan nos resulten familiares y podamos estimarlas. Esto es un error. Reflexionemos, si no tenemos experiencia con este tipo de funcionalidad, ¿cómo vamos a ser capaces de hacer el análisis y diseño técnico de la funcionalidad para descomponerla en tareas de forma precisa? Sí, podemos hacer esta descomposición, pero seguramente esté mal, o nos falten tareas o no hayamos tenido en cuenta las peculiaridades (para nosotros desconocidas) de esa funcionalidad o proyecto. Existe otra forma mejor, y es hacer una prueba de concepto, o “spike”. Invirtamos algo de dinero en hacer una implementación a pequeña escala de lo que queremos estimar, y usemos el conocimiento adquirido para hacer nuestra estimación. Sí, es más caro y lento, no es perfecto, pero es menos arriesgado que el enfoque anterior.

Finalmente, desde un punto de vista más específico de Scrum, existe otra razón para no estimar las tareas. Recordemos que la planificación en Scrum se basa en el ordenamiento de ítemes en el backlog en función de su ROI. El ROI se entiende como la relación entre el valor del ítem y su coste y/o tamaño. Es decir, en Scrum no sólo se estima el coste sino el valor. Si descompongo una funcionalidad en tareas y estimo cada tarea por separado, no sólo debo estimar el coste de cada una de ellas, sino su valor. Como el valor de una tarea es cero, el ROI de cada tarea es cero también. ¡ Si sumo el ROI de todas las tareas me sale que el ROI de la funcionalidad es cero ! Esto ocurre debido a que hemos sido inconsistentes y hemos cambiado de nivel de abstracción alegremente. Una señal de que hemos violado el nivel de abstracción pertinente es que las cuentas no salen, ya que el todo es mayor que la suma de las partes.

En el próximo post contaré algunas técnicas de estimación ágiles.

La verdad es que existe bastante controversia entre si es conveniente estimar o no y cómo ha de hacerse correctamente. Los que me conocéis ya estareis anticipando mi respuesta: estima sólo lo justo y necesario y no te esfuerces en ser más preciso de lo que realmente necesitas o puedes. Este es el enfoque que cualquier profesional pragmático debería usar y olvidarse de cualquier postura “idealista”. Para aplicar esta idea en la práctica debemos antes tener claro qué es estimar, cuál es nuestro objetivo a la hora de estimar, y que grado de precisión podemos esperar de forma realista de nuestras estimaciones.

En el contexto del desarrollo de software, estimar es la actividad que realizamos para predecir el coste de realizar una tarea y/o implementar una unidad de funcionalidad, basándonos en nuestra experiencia pasada con tareas o funcionalidades similares. ¿Qué grado de precisión podemos esperar de tales estimaciones? Pues básicamente todo depende de la cantidad de experiencia que tengamos. Si no hemos tenido experiencia en tareas similares en el pasado, nuestra estimación resultará inútil. Ojo, experiencia en actividades similares, no experiencia en cualquier cosa. Por lo tanto sólo existen dos maneras sensatas de estimar:

• Usar un sistema informático, que gracias a una amplia base de datos de mediciones de cuanto se tardó realmente en el pasado en hacer tareas similares, y mediante un modelo estadístico, nos ofrezca un intervalo de confianza de cuanto esfuerzo necesitaremos en realizar una tarea. Hago énfasis, intervalo de confianza, no una “media”.
• Usar personal experto en el entorno tecnológico que se va a usar, que tenga un entendimiento claro de la tarea que se va a hacer y con experiencia a sus espaldas. Este personal de nuevo nos podrá ofrecer un intervalo como estimación.

En este sentido no debería estimar ni el cliente, ni personal senior pero no familiarizado con la tecnología a usar, ni nadie no implicado en la construcción del software. Esto coincide con lo que nos dice Scrum de que sea el equipo de desarrollo quien estime y no el PO. Sin embargo tampoco recomiendo que estime el personal junior, tal vez puede intentar estimar para aprender, pero no habría que darle mucho peso a su estimación. Quizás esto último no sea muy ágil, pero a mi me parece de sentido común.

En cualquier caso, existe un límite natural a la precisión de nuestras estimaciones:

• Cuanta menos variabilidad exista entre las tareas mejor estimaremos, ya que nuestra experiencia pasada será más representativa. Variabilidad en cualquier aspecto: tecnología, tamaño, complejidad, funcionalidad, etc.
• Las predicciones sobre tareas/funcionalidades grandes son menos precisas que las hechas sobre tareas más pequeñas. Esto es especialmente cierto si hablamos de precisión relativa (%).
• Las predicciones a largo plazo son siempre menos precisas que las hechas a corto plazo. Esto es debido a que cuanto más tiempo pueda transcurrir, más posibilidad hay de que ocurran imprevistos o de que las circunstancias cambien o varíen.
• La experiencia más reciente suele ser más representativa que la más antigua, ya que se han podido producir cambios en nuestro entorno. Por ejemplo: nuevas tecnologías, cambios en el equipo (para mejor o para peor), etc.
• El ser humano es mejor estimando por comparación entre objetos del mismo tipo. Somos muchos más precisos adivinando que una tarea es aproximadamente un 50% más grande que otra tarea del mismo tipo, que intentando asignar tiempo o dinero directamente a cada tarea por separado.

O sea, para que tenga sentido el esfuerzo y dinero que vamos a gastar en estimar se deben cumplir algunos prerrequisitos:

• Tener personal con experiencia en las tareas y tecnologías implicadas.
• Que haya poca variabilidad en las tareas a estimar, es decir, que sean similares en todos los aspectos relevantes.
• No malgastar esfuerzos, y usar un grado de precisión realista a la hora de estimar, en función del tamaño de lo que estemos estimando y la escala de tiempo. Podemos hacer una estimación grosera, en meses, de una tarea que está en la escala de años, y una más fina de horas para una tarea que está en la escala de una jornada, pero es absurdo estimar con precisión de días una tarea en la escala de un año.
• Usar estimaciones relativas (por comparación) en vez de absolutas. Es importante no comparar dos cosas que estén en escalas distintas, tanto de tamaño como de tiempo.

Mientras no se cumplan los anteriores requisitos no tiene sentido ponerse a estimar, ya que simplemente los resultados obtenidos no nos servirán de nada. Si no se cumplen estos requisitos lo mejor es “adivinar” y “tirarse a la piscina”, ya que es igual de preciso pero más barato.

¿Radical? Pensadlo bien ¿Para que queremos estimar? En el fondo siempre que estimamos lo hacemos para asumir un compromiso con nuestro cliente, ya sea directamente o indirectamente a través de nuestros jefes: ¿cuándo estará terminado? ¿Podréis acabar esta funcionalidad antes de la semana que viene? ¿Te comprometes a hacer el proyecto en este tiempo y con tanto dinero? El hecho de asumir un compromiso nos lleva a correr el riesgo de no cumplirlo, y como tal lo debemos evitar a no ser que sea absolutamente necesario. En caso de que realmente necesitemos comprometernos formalmente debemos evaluar el nivel de riesgo de no cumplir esta promesa, lo cual depende sobre todo de la precisión de nuestra estimación. Por lo tanto, siguiendo el razonamiento de este post, no tiene sentido estimar si nuestra precisión no es aceptable, ya que estaríamos ante un riesgo incontrolado.

Así que ya sabeis, la próxima vez que monteis un plan de proyecto para un proyecto cerrado, o que comprometais una fecha de entrega, pensad antes si vuestras previsiones realmente tienen sentido, y no gasteis dinero en absurdos cálculos basados en cosas como los “puntos función”.

En próximos post abordaré la polémica sobre si estimar tareas o funcionalidades, y distintas técnicas ágiles para hacerlo.

Un refactor es una transformación de código que no altera la funcionalidad de este, pero sí su estructura. La idea es hacer refactors que hagan que nuestro código sea más flexible y maleable para poder alterarlo de forma rápida. El truco está en saber si al aplicar un refactor estamos mejorando nuestro código o si simplemente lo estamos complicando ¿Qué criterios sigo yo para evaluar si un refactor es bueno o no? Básicamente sólo sigo los tres siguientes:

• Que el código resultante sea más legible.  Como ya expliqué considero este el criterio más importante.
• Que se respeten los principios DRY y “experto en información”. Ya los explicaré en otro post
• Que se respeten los principios SOLID. Entre este post y los siguientes pienso ir explorándolos.

¿Qué es el SOLID? SOLID es un acrónimo que consolida 5 principios: Single responsability, Open/Closed, Liskov substitution, Interface segregation y Dependency inversion. En este post me ocuparé del principio de única responsabilidad (Single responsability o SRP), o sea la S  de SOLID.

El principio de única responsabilidad (SRP) simplemente nos dice que ningún artefacto de código debe tener más de una única responsabilidad, y por lo tanto debe implementar una única funcionalidad. El principio aplica a sistemas, aplicaciones, frameworks, objetos y métodos. Obviamente según el artefacto al que se aplique, la amplitud del concepto de única responsabilidad cambia. Pero en este post nos vamos a centrar en cómo afecta a nuestra clases y objetos.

¿Cómo sabemos si un artefacto, como una clase o un método, respeta este principio? Es muy sencillo, simplemente  debemos preguntarnos a nosotros mismos sobre cuantas razones diferentes podemos tener para querer cambiar dicho artefacto. Un artefacto que cumple el principio de única responsabilidad sólo puede ser cambiado debido a una única razón. Si encontramos múltiples razones para cambiar un artefacto entonces no cumple dicho principio y debe ser refactorizado. A mi me gusta llamar a este principio, el principio del bombero/torero. El hecho de que el personaje de bombero/torero nos cause risa es que es totalmente ridículo que una misma persona realice tareas de dos profesiones tan diferentes al mismo tiempo. Si lo vemos absurdo en una persona, ¿porque nos quedamos tan tranquilos cuando vemos una clase que es un bombero/torero?

Para entender mejor este principio veamos un ejemplo. Suponed que tenemos una historia de usuario tal que sigue:

“Cuando se realiza una transferencia importante

Entonces se genera un mensaje con información sobre dicha transferencia

Y se notifica a las personas de interés

Para que den su aprobación y así evitar el fraude fiscal”

Hablando con el cliente me dice que la persona de interés es un auditor, y que había pensado en notificarle vía mail. Las transferencias importantes son aquellas por encima de 1000 euros (son un poco ratas). Cómo estoy codificando en JAVA y usando el famoso framework Zprin, el código que me sale es el siguiente:

public class AuditorTransferenciasMonetarias {
  // Inyección de dependencias con el famoso framework Zprin (TM)
  // Con este framework somos productivos de la leche
  private ZprinPropertySource systemConfiguration;
  private ZprinTemplateEngine templateEngine;
  private ZprinMailIt mailIt;

  public void transferenciaRealizada(Transferencia transferencia) {
    if(this.esTransferenciaImportante(transferencia)) {
      String auditor=this.obtenerDireccionMailAuditor();
      String mensaje=this.componerMensajeAviso(transferencia);
      ConexionMail conexionMail=null;
      try {
        conexionMail=this.abrirConexionMail();
        conexionMail.enviar(new Mail().to(auditor).withBody(mensaje));
      } finally {
        if(conexionMail!=null)
          conexionMail.cerrar();
      }
    }
  }
  private boolean esTransferenciaImportante(Transferencia transferencia) {
    return transferencia.importe()>1000;
  }
  private String obtenerDireccionMailAuditor() {
    return this.systemConfiguration.getProperty("auditor.email");
  }
  private String componerMensajeAviso(Transferencia transferencia) {
    return this.templateEngine.getTemplate("aviso-transferencia-importante.ztpl").execute(transferencia);
  }
  private MailConnection abrirConexionMail() {
    return this.mailIt.openConnectionTo(this.systemConfiguration.getProperty("servers.mail"));
  }
}

Buen código, al usar el framework soy muy productivo y hago la clase super rápido, es más me quito de encima problemas complejos como el envío de mails, el acceso a propiedades configurables, o el tener que hacerme un motor de plantillas Sólo tiene un problema, que no cumple el SRP (maldito SOLID, quién lo habrá inventado). SRP nos dice que la clase sólo debe tener una responsabilidad y la única manera en la que esta debería tener que cambiarse es cuando hay alguna alteración en dicha responsabilidad. En este caso la responsabilidad viene definida por la historia de usuario, así que mientras esta no cambie de forma significativa, entonces no deberíamos vernos forzados a cambiar la implementación. Obviamente el código descrito arriba no cumple esta propiedad. Vayamos por partes.

Suponed que el criterio para clasificar a una transferencia como importante cambia. Nos veríamos forzados a tocar nuestra clase, aunque realmente nuestra historia de usuario es la misma. Para evitarlo alteramos nuestro código:

public class AuditorTransferenciasMonetarias {
  // ....
  public void transferenciaRealizada(Transferencia transferencia) {
    if(transferencia.esImportante()) {
      String auditor=this.obtenerDireccionMailAuditor();
      String mensaje=this.componerMensajeAviso(transferencia);
      ConexionMail conexionMail=null;
      try {
        conexionMail=this.abrirConexionMail();
        conexionMail.enviar(new Mail().to(auditor).withBody(mensaje));
      } finally {
        if(conexionMail!=null)
          conexionMail.cerrar();
      }
    }
  }
  // ....
}

Como vemos ahora la clase Transferencia tiene un método que nos indica si es importante o no. Si el criterio de importancia cambia nos da igual, ya que este método nos protege de dicho cambio. Si el cliente decide que quiere un motor de reglas parametrizable en runtime mediante un backoffice, el afectado es Transferencia no la clase que estamos construyendo.

Otro motivo de cambio ajeno a nuestra responsabilidad es que la definición de “personas interesadas” cambie. De repente queremos notificar no sólo a un auditor, sino a varios y además al director de la sucursal. Para protegernos de ello veamos el siguiente cambio:

public class AuditorTransferenciasMonetarias {
  // ....
  // Ahora tenemos un colaborador de "negocio"
   // que está al mismo nivel de abstracción que esta clase
  private DirectorioEmpleados directorioEmpleados;

  public void transferenciaRealizada(Transferencia transferencia) {
    if(transferencia.esImportante()) {
      String mensaje=this.componerMensajeAviso(transferencia);
      ConexionMail conexionMail=null;
      try {
        conexionMail=this.abrirConexionMail();
        conexionMail.enviar(rellenarDestinatarios(new Mail().withBody(mensaje)));
      } finally {
        if(conexionMail!=null)
          conexionMail.cerrar();
      }
    }
  }
  private Mail rellenarDestinatarios(Mail mail) {
    for(Empleado interesado: this.interesadosEnTransferenciasImportantes())
      mail=mail.to(interesado.email());
    return mail;
  }
  private List<Empleado> interesadosEnTransferenciasImportantes() {
    return this.directorioEmpleados.empleadosConRol(Empleado.INTERESADOS_TRANSFERENCIAS_IMPORTANTES);
  }
  // ....
}

Ahora gracias a la interface DirectorioEmpleados, podemos buscar a todos los empleados que necesitamos notificar. Para ello buscamos por rol. La asociación empleado/rol se puede definir aparte, e incluso ser dinámica y cambiar en runtime. Observad que hemos añadido un colaborador que está al mismo nivel de abstracción de la clase que estamos codificando, y que el código ahora se parece un poco más a la definición de la historia de usuario.

Otro motivo por el cual podemos vernos obligados a cambiar esta clase, es que ahora los mensajes no se envíen por mail, sino por SMS. O peor, ¡ que se envíen a la vez por SMS, Mail, y chat a la vez ! Como no queremos que nos pillen con eso (que me conozco al cliente, que cambia de opinión constantemente) volvemos a “mejorar” el código:

public class AuditorTransferenciasMonetarias {
  // ...
  private SistemaMensajeriaCorporativa mensajero;

  public void transferenciaRealizada(Transferencia transferencia) {
    if(transferencia.esImportante()) {
      this.mensajero
            .enviar(
              new Mensaje()
                   .a(this.interesadosEnTransferenciasImportantes())
                   .conContenido(this.componerMensajeAviso(transferencia))
      );
    }
  }
  // ....
}

Esta vez hemos introducido el sistema de mensajería corporativa, que nos permite enviar un mensaje de forma abstracta a varios empleados. Ya está, ya no hay más motivos de cambio… no perdón nos queda otro motivo y gordo. Hablando con nuestro amigo el “friki”, nos cuenta que el framework Zprin ya no es el acabose y que ha salido el framework XprinGio, y que a Zprin se queda sin soporte en menos de dos años. Nos olemos la tostada, en cuanto se entere el arquitecto jefe del temita nos manda cambiar de framework, o peor, si se entera el jefe de proyecto que sólo nos quedan dos años de soporte, toma migración. Hay que protegerse a toda costa de tan temida migración:

public class AuditorTransferenciasMonetarias {
  private DirectorioEmpleados directorioEmpleados;
  private SistemaMensajeriaCorporativa mensajero;
  private PlantillasCorporativas almacenDePlantillas;

  public void transferenciaRealizada(Transferencia transferencia) {
    if(transferencia.esImportante()) {
      this.mensajero
            .enviar(
              new Mensaje()
                   .a(this.interesadosEnTransferenciasImportantes()
                   .conContenido(this.componerMensajeAviso(transferencia))
      );
    }
  }
  private Documento componerMensajeAviso(Transferencia transferencia) {
    return this.almacenDePlantillas.usandoPlantilla("avisos/transferencia-importante").crearDocumentoCon(transferencia);
  }
  private List<Empleado> interesadosEnTransferenciasImportantes() {
    return this.directorioEmpleados.empleadosConRol(Empleado.INTERESADOS_TRANSFERENCIAS_IMPORTANTES);
  }
}

Esta vez hemos eliminado todo dependencia con Zprin, y tenemos un motor de plantillas abstracto. Obviamente cuando implementemos el motor de plantillas, o el sistema de mensajería nos acoplaremos a Zprin, pero en una posible migración, sólo tendremos que cambiar estos servicios y no todas las clases de negocio. Otro cambio es que ahora la plantilla genera un Documento en vez de un String. Además la clase Documento sabrá serializarse en cualquier formato que se necesite por parte del mecanismo de mensajería (String, XML, HTML, JSON, PDF…) lo que permite tener sistemas de mensajería más complejos.

Como se observa, si seguimos el principio de única responsabilidad nuestros artefactos tendrán una alta cohesión y por lo general un bajo acoplamiento, ya que quedan pocos métodos muy relacionados entre si y muy cortos. Pero lo mejor es que se tenderá a que la tasa de cambios de un único artefacto baje, y que éstos cambios sean más localizados, ya que sólo se va a necesitar modificarlo ante un único tipo de cambio al existir una relación uno a uno entre responsabilidad y clase. Obviamente este era un ejemplo de código algo artificial, y seguro que le sacais pegas, pero creo que podéis captar la idea.

Pero no es oro todo lo que reluce, más adelante en esta serie veremos el principio DRY y el “experto en información” y como ambos se terminan pegando con el principio de única responsabilidad, con lo que se produce un conflicto grave. Para colmo, el principio de segregación de interfaces nos puede complicar también la vida. Armonizar todos estos principios, es el caballo de batalla del diseño orientado a objetos. De hecho, respetar cada principio por separado es sencillo, lo difícil es juntarlos todos, ya que veréis que es como si unos principios contradijeran a otros ¿Terminará siendo la OO en realidad un paradigma fracasado y contradictorio?

En la conferencia me percaté de que varios temas se repetían una y otra vez en las distintas charlas: Grails, Cloud Computing, noSQL y “Portable Service Abstractions”. Comentaré primero lo que se habló sobre cada uno de estos temas y después explicaré porqué todos ellos me hacen pensar que VMWare se postula como seria competencia de Oracle.

Sin saber mucho de Grails, me da la impresión que es un framework “orientado a la base de datos”. En los ejemplos que he visto siempre se habla del MVC, pero todos los modelos Grails que he visto no son más que JavaBeans (a.k.a. registros COBOL recauchutados), eso sí, codificados en Groovy, que es mas “cool”. Después tienes las vistas, que no son más que JSPs (perdonad, GSPs) y un controlador escrito en Groovy que en realidad es un controlador de Spring MVC (que es casi igual a un backing bean de JSF). Vamos, más modelo anémico. Ciertamente es mucho mejor que un modelo anémico que podamos hacer en JAVA, y sí, no hay que picar apenas código (se agradece), con lo cual considero a Grails la plataforma perfecta para este tipo de aplicaciones. Si estoy metiendo la pata perdonadme, pero ya sabéis que me hierve la sangre con este tema ¡ Si alguien sabe como hacer buena OO con Grails que me lo diga !

Dejando de lado esta diatriba, la charla a la que asistí de Grails fue muy interesante. Peter Ledbrook explicó de forma bastante clara como integrar Grails con el resto de la empresa. ¿Qué hacemos si queremos hacer un build con ANT? ¿Y con MAVEN? ¿Y si ya existe un modelo hecho con JPA? ¿Y si resulta que el administrador de base de datos nos obliga a una determinada nomenclatura? La verdad es que resolvió bastante bien todos estos escenarios, aunque la parte de integración con MAVEN me dio la impresión de estar un pelín verde. Quizás el mayor problema es cuando ya existe un esquema de base de datos que tenemos que respetar. Aquí es donde la solución que dio no me terminó de parecer clara, y me pareció que proponía que se hiciera un modelo JPA y se integrara éste modelo con Grails. Está claro que en SpringSource se han dado cuenta de que uno de los obstáculos principales para que Grails triunfe es poder integrarse con los elementos más usuales en un sistema empresarial.

Otro punto que se habló de Grails fue integrar GORM (motor de mapeo Objeto/Relacional de Grails) con bases de datos noSQL. Se mencionó este tema en la segunda key note e @ialcazar me comentó un poco sobre una sesión que se dio a este respecto. No termino de ver como se puede integrar un motor de mapeo objeto/relacional con una base de datos no relacional ¡ Precisamente una de las ventajas de una base de datos noSQL es que no necesitamos un mapeo Objeto/Relacional ! No termino de verle el sentido técnico, pero sí el de marketing. En cualquier caso creo que es una iniciativa muy interesante de la comunidad de Grails, esperemos que lo consigan sin cargarse la escalabilidad que nos da un noSQL. También noté preocupación por el rendimiento de Grails, y se ve que están trabajando muy duro para mejorarlo.

Otro tema que estuvo bastante presente fue el Cloud Computing. Durante la primera key note y alguna que otra charla se habló de que el objetivo a medio plazo es preparar a Spring para permitir desarrollar aplicaciones en la nube. Realmente no termino de ver que problema hay con las APIs actuales de Spring y la nube, así que todo esto me suena a simple marketing. En este sentido me hubiera gustado que hablaran de tecnologías como vFabric o GemFire, pero claro, aunque son parte de VMWare, técnicamente no forman parte de Spring, con lo que hubiera estado fuera de lugar nombrarlas. Tal vez cuando se hablaba de adaptar Spring a la nube se refirieran a conseguir mayor rendimiento, y sobre todo escalabilidad y elasticidad, cosa fundamental en este tipo de entornos.

Quizás en este sentido se entienda el esfuerzo por integrarse con sistemas de persistencia noSQL, que proporcionan mayor escalabilidad a las aplicaciones. Una de las charlas más interesantes fue la de Spring Data de Costin Landau. Realmente me gustó la propuesta de Spring de montar un API “estándar” para noSQL, sobre todo teniendo en cuenta que JEE no proporciona nada comparable. En concreto las APIs de bajo nivel y el concepto de “repositorio” me resultó interesante. También la idea de dar cobertura a bases de datos documentales y orientadas a grafos me resultó bastante atractiva. Sin embargo a otras propuestas, como incorporar un sistema de persistencia mixto que mantuviera parte del modelo en BBDD relacional y parte en noSQL no acabo de verles el sentido. Tal vez sea un compromiso de “marketing” para que a la gente no le de miedo adoptar noSQL, ya que seguirían teniendo el respaldo de bases de datos tradicionales. A mi simplemente me parece una postura originada por el miedo de la gente a noSQL. Ya sabéis que pienso que si el sistema tiene las consultas bien definidas, el enfoque noSQL es totalmente superior al tradicional, y que sólo usaría un sistema SQL si realmente el conjunto de consultas las va a decidir el usuario en runtime, como son el caso de bussiness inteligence y data mining por ejemplo.

En la línea de noSQL la charla sobre Redis de Alberto Gimeno fue curiosa. Personalmente pienso que Redis está un poco verde todavía, aunque a alguno le puede interesar el concepto de clave/valor avanzado. Al contrario que un clave/valor simple, el valor almacenado puede ser no sólo un array de bytes, sino estructuras de datos como contadores, listas, mapas o sets. Para cada tipo de datos REDIS proporciona un conjunto de operaciones específicas, que se pueden ejecutar de forma atómica, y extienden el paradigma clásico del clave/valor. No termino de ver por qué esta complejidad extra es necesaria, pero sí que es verdad que facilita a un recién llegado al noSQL la transición desde el mundo de las BBDD relacionales. En todo caso me alegró ver que la gente empieza a usar sistemas noSQL, ya sabéis de que pié cojeo.

Otro tema que fue hilo conductor de esta conferencia fue el concepto de “Portable Service Abstraction”. Este nombre es una forma “cool” de decir que si desarrollamos contra interfaces “estándar”, nuestro código será portable a otros entornos. Es una idea muy vieja, y es lo que intentó JEE. Como ejemplos de estas “Portable Service Abstraction” podemos tener Spring Data, Spring REST, Spring AMQP, Spring Social, Spring Mobile y Spring Android. En general me gusta el enfoque de Spring de hacer APIs sencillas, y de reaccionar de forma rápida y ágil a las necesidades de los desarrolladores. Sin embargo no es oro todo lo que reluce. No entiendo la necesidad de Spring REST, desde mi punto de vista JAX-RS era un estándar más que suficiente. De hecho ambos estándares son tan similares, que es difícil distinguir dos aplicaciones hechas sobre cada una de ellas. Por otro lado Spring Mobile y Spring Android me decepcionaron, ya que apenan aportan valor. El primero básicamente sólo te detecta el tipo de dispositivo móvil y te redirige a una página de presentación u otra en función de éste. Vamos, nada que no exista ya en las múltiples arquitecturas multicanal “clásicas”. Spring Android es sólo un cliente para hacer llamadas al servidor. Los que sí me gustaron bastante fueron Spring Social, Spring Data y Spring AMQP. En concreto este último, ya que me pareció que el RabbitMQ era genial.

Toda esta información que recibí en la SpringIO me hizo ver que VMWare está intentando atacar a Oracle por varios frentes:

• Spring como substituto de JEE. Aunque Spring es compatible con JEE, en el fondo lo que pretende es que programemos contra sus APIs en vez de las de JEE, aduciendo motivos de portabilidad. Esto es gracioso, ya que JEE nos propone exactamente lo mismo: una aplicación programada contra JEE es portable al ser éste el estándar de iure para el desarrollo de aplicaciones empresariales. Así que, ¿cuál API es más estándar, JEE o Spring? Esta claro que Spring ha sabido evolucionar sus APIs de forma más ágil y práctica que JEE, con todos sus comités. Todo esto es una amenaza clara contra Oracle, que es la actual “dueña” de JEE.
• Tomcat y Spring tc Server como substitutos de WebLogic (y de paso de WebSphere). Si vamos a programar contra Spring en vez de contra JEE no tiene sentido comprar un servidor JEE completo como WebLogic o WebSphere, nos basta un contenedor de Servlets como Tomcat. Para los que no lo sepáis WebLogic es de Oracle.
• AMQP y RabbitMQ contra JMS. Aunque RabbitMQ se integra con JMS, en realidad es una alternativa viable a JMS, y a cosas como MQSeries.
• Grails como substituto de JSF. Como ya sabréis el modelo de programación web JEE es JSF. De hecho Oracle ha invertido en su implementación de JSF, llamada Oracle ADF, y en un IDE especial para ADF basado en Eclipse. Oracle ADF y su IDE nos permite hacer aplicaciones orientadas a base de datos muy rápidamente (o eso me han contado). Está claro que SpringToolSuite junto con Grails es competencia directa de esta tecnología.
• noSQL contra las bases de datos relacionales. Como sabéis Oracle es dueña no sólo de la base de datos relacional más famosa del mundo, sino que con la compra de Sun, puede hacerse con el control de MySQL. Obviamente apostar por noSQL es un golpe directo a la linea de flotación de Oracle. Curiosamente el único sistema noSQL del que se habló con detalle en la conferencia fue de REDIS, que está “esponsorizado” por VMWare.
• Cloud Computing contra hosting tradicional. El Cloud Computing es un escenario que creo beneficia más a VMWare que a Oracle. El primero, ha hecho una apuesta fuerte en este sentido con vFabric y vmForce. Si tienes una instalación propia, puede venir un comercial de Oracle a venderte WebLogic y la base de datos de turno. En un cloud no. Si convences a una empresa para irse al cloud, es más que probable que sus bases de datos Oracle queden en desuso.

En definitiva, Spring pretende suplantar a JEE como plataforma estandarizada para el desarrollo de aplicaciones empresariales con JAVA. Bueno, tal vez yo sea un poco suspicaz, pero esto es lo que realmente leo entre lineas de la conferencia SpringIO. Por cierto fue un éxito de público, y en general el nivel de las sesiones y talleres fue bastante alto. Enhorabuena a la organización, ya que no creo que con 20 euros se pudiera haber hecho mejor. ¿A alguien le pareció caro? A mi no.

Este es uno de los posts más difíciles que he hecho ya que voy a intentar mostrar mis procesos mentales de diseño, y como me enfrento a un problema de programación (sencillo por cierto). Aviso a los asistentes del coding dojo que el código final al que llego en este post es diferente al que hizo @ecomba, lo que demuestra que no suele existir una única implementación “óptima”, y que el resultado puede variar en función de criterios personales y algo del azar. No tengo experiencia alguna en Ruby, sólo he hecho los koans y esta kata, con lo que he usado un Ruby muy básico y sencillo al no conocer bien el lenguaje y la librería de objetos. Sin embargo guiado por el TDD y el refactor creo que llego a una solución bastante compacta. Empecemos…

Lo primero de todo es familiarizarse con la funcionalidad a implementar. Ni el TDD ni el refactor son un sustituto de ponerse a pensar, sólo un guía para nuestro proceso creativo, por lo que debemos tener alguna idea del objetivo funcional que debe alcanzar nuestro código. No es necesario ser un experto en la funcionalidad, sino saber por donde van más o menos los tiros y no ir dando palos de ciego. Aquí va la funcionalidad de los números romanos, al menos lo que recordaba cuando me puse a tirar código:

• Queremos convertir un número entero en un número romano. Nada más.
• Los romanos no representaban de forma explícita ni el cero ni los números negativos.
• Existen un conjunto de 13 símbolos o numerales básicos (nosotros tenemos 10). Cada uno de estos tiene un valor predefinido, pero ninguno representa el 0 o valor negativo.
• Para representar un número, se concatenan estos numerales, y sus valores se van sumando hasta que se obtiene el valor del número.
• Algunos casos como el 4 o el 9 son especiales y se representan de forma especial.

Así que llegué a mi casa, abrí el vim, me instalé el rspec y secuestré el “mug of vi” de mi mujer para que me sirviera de chuleta (soy penoso con el vi y quería aprender, que lo pasé muy mal en el dojo). Lo primero que se hace siempre es coger el caso más básico, y que cosa más básica que el número 1. En rspec queda:

describe "Roman number" do
	it "I is equivalent to 1" do
		1.to_roman.should == 'I'
	end
end

Evidentemente falla, con lo que hay que añadir una implementación. Pero siguiendo las reglas del TDD y refactor, debe ser la implementación más simple posible que pase el test, ya lo pondremos bonito después si existiera una razón de peso. Para los que no sepan Ruby, en éste lenguaje las clases son abiertas, por lo que el enfoque de diseño tomado es añadir un método “to_roman” a la clase “Fixnum” que representa a los enteros.  La implementación es obvia:

class Fixnum
	def to_roman
		'I'
	end
end

describe "Roman number" do
	it "I is equivalent to 1" do
		1.to_roman.should == 'I'
	end
end

Vamos a probar ahora con el número 5, que es otro de los numerales básicos romanos. La estrategia de momento es ir añadiendo numerales básicos, a ver que nos sale. El test y su correspondiente implementación:

class Fixnum
	def to_roman
		return 'V' if self == 5
		'I'
	end
end

describe "Roman number" do
	it "I is equivalent to 1" do
		1.to_roman.should == 'I'
	end

	it "V is equivalent to 5" do
		5.to_roman.should == 'V'
	end
end

La técnica es sencilla, copiar y pegar lo que funcionó en el caso del 1. Reemplazamos los valores adecuados y cubrimos cada caso con un if. Estamos en modo “pasar tests”, hasta el momento no hemos detectado duplicación y no hemos refactorizado nada. Pero esto ya empieza a oler a cuerno quemado. Volvemos a repetir, esta vez para el 10. La cosa queda:

class Fixnum
	def to_roman
		return 'X' if self == 10
		return 'V' if self == 5
		'I'
	end
end

describe "Roman number" do
	it "I is equivalent to 1" do
		1.to_roman.should == 'I'
	end

	it "V is equivalent to 5" do
		5.to_roman.should == 'V'
	end

	it "X is equivalent to 10" do
		10.to_roman.should == 'X'
	end
end

Ya se observa claramente la duplicación. Tenemos dos (o tres, según se mire) lineas con la misma estructura de código. Esto es normal ya que hemos estado haciendo copy&paste. Ahora toca reflexionar sobre la intención de nuestro código, ¿qué queremos hacer en realidad? ¿Refleja el código actual esa intención (es expresivo)? Es obvio que lo que queremos hacer es mapear números a numerales romanos, y que existe una correspondencia uno a uno. En realidad estamos haciendo una búsqueda de un literal romano por número entero a base de un montón de ifs. El uso de una simple Hash (o mapa o diccionario) nos elimina las líneas duplicadas y nos da un código más expresivo (si elegimos bien los nombres). Tras refactorizar me sale lo siguiente:

class Fixnum
	ARABIC_TO_ROMAN_NUMERAL = { 10 => 'X', 5 => 'V', 1 => 'I' }

	def to_roman
		ARABIC_TO_ROMAN_NUMERAL[self]
	end
end
# .......

Por brevedad no me entretendré con los siguientes 10 numerales romanos, y pasaré al siguiente problema, ¿qué pasa si un número no se corresponde con un literal romano? Según el funcional hay que concatenar los numerales hasta sumar el número deseado. Como caso más sencillo de este escenario añado el test para el número 2 que debe transformarse en ‘II’. Además voy a refactorizar un poco los ejemplos de test, agrupándolos por escenario. En RSpec usaré un contexto por escenario (no se si esto es purista pero a mi me parece bien). El test ahora es:

# .........
describe "Roman number" do
	context "has basic numerals with different values" do
		it "I is equivalent to 1" do
			1.to_roman.should == 'I'
		end

		it "V is equivalent to 5" do
			5.to_roman.should == 'V'
		end

		it "X is equivalent to 10" do
			10.to_roman.should == 'X'
		end
	end

	context "concatenates numerals in descending order until they sum up the desired integer" do
		it "II is equivalent to 2" do
			2.to_roman.should == 'II'
		end
	end
end

Como veis un contexto para los numerales básicos y otro para los que no lo son. Añado la implementación más básica que se me ocurre, si el número coincide con un numeral básico lo devuelvo y acabo, si no, devuelvo ‘II’ a cascoporro:

class Fixnum
	ARABIC_TO_ROMAN_NUMERAL = { 10 => 'X', 5 => 'V', 1 => 'I' }

	def to_roman
		return ARABIC_TO_ROMAN_NUMERAL[self] if ARABIC_TO_ROMAN_NUMERAL[self]
		'II'
	end
end
# ........

Añado un test para el número 3, que debe resultar en ‘III’ y su correspondiente implementación. Pero esta vez me lo curro un poco más:

class Fixnum
	ARABIC_TO_ROMAN_NUMERAL = { 10 => 'X', 5 => 'V', 1 => 'I' }

	def to_roman
		return ARABIC_TO_ROMAN_NUMERAL[self] if ARABIC_TO_ROMAN_NUMERAL[self]
		'I' + (self - 1).to_roman
	end
end

describe "Roman number" do

#      ......................

	context "concatenates numerals in descending order until they sum up the desired integer" do
		it "II is equivalent to 2" do
			2.to_roman.should == 'II'
		end

		it "III is equivalent to 3" do
			3.to_roman.should == 'III'
		end
	end
end

Como veis esta vez he sido más sofisticado y en vez de meter un ‘III’ if self == 3, he leído bien el funcional y se me ha ocurrido un algoritmo. Siguiendo el espíritu de concatenar hasta sumar el número, se me ocurre que puedo tomar el numeral ‘I’ y restarle su valor al número que quiero convertir. El resultado de esta resta, qué es lo que queda para conseguir sumar el número deseado, lo convierto a su vez en un número romano y lo concateno. Aquí hemos tenido que parar y reflexionar sobre la funcionalidad para obtener una idea creativa. El TDD nos ha servido para llegar a un punto donde esta idea se nos pueda ocurrir con facilidad.

Sigamos, ¿qué pasa con otros casos? Añado tests para el 6, el 11 el 15 y el 20. Los hago pasar haciendo copy&paste del caso del 2 y el 3, reemplazando ‘I’ y 1, por ‘V’ y 5 para pasar el test del 11, y ‘X’ y 10 para pasar el test del número 9. La cosa queda así:

class Fixnum
	ARABIC_TO_ROMAN_NUMERAL = { 10 => 'X', 5 => 'V', 1 => 'I' }

	def to_roman
		return ARABIC_TO_ROMAN_NUMERAL[self] if ARABIC_TO_ROMAN_NUMERAL[self]
		return 'X' + (self - 10).to_roman if self > 10
		return 'V' + (self - 5).to_roman if self > 5
		'I' + (self - 1).to_roman
	end
end

describe "Roman number" do

#      .................

	context "concatenates numerals in descending order until they sum up the desired integer" do
		it "II is equivalent to 2" do
			2.to_roman.should == 'II'
		end

		it "III is equivalent to 3" do
			3.to_roman.should == 'III'
		end

		it "VI is equivalent to 6" do
			6.to_roman.should == 'VI'
		end

		it "XI is equivalent to 11" do
			11.to_roman.should == 'XI'
		end

		it "XV is equivalent to 15" do
			15.to_roman.should == 'XV'
		end

		it "XX is equivalent to 20" do
			20.to_roman.should == 'XX'
		end
	end
end

Fijaros en el orden en que pongo las líneas de código, primero evalúo los numerales con valor más alto y después las de valor más bajo. Si lo hacemos en otro orden los tests fallan, al devolverme por ejemplo ‘VVI’ en vez de ‘XI’. En este caso los tests son los que nos han hecho darnos cuenta de que hay que ordenar los numerales de mayor a menor, y además de sumar el valor, debe ser la representación más corta posible. Esto no lo tenía yo nada claro por el funcional que indiqué más arriba. En este caso los tests nos aclaran la funcionalidad.

Sin embargo de nuevo tenemos duplicación y el código da repelús. La misma estructura de código repetida en tres líneas, sólo varía en el numeral romano usado en cada caso y su correspondiente valor numérico. ¿Podemos sustituir esta duplicación por una regla parametrizable? ¿Quizás un método auxiliar que recibiera como parámetros el numeral romano y el valor numérico? Esta solución eliminaría algo de duplicación, pero aun quedaría duplicada la estructura de la cascada de ifs. Es esto último lo que más me preocupa, ya que se viola el principio abierto/cerrado. Cuando quisiéramos añadir un nuevo numeral (cuando nuestro cliente recordara uno nuevo), tendríamos que “abrir” el método to_roman para añadir otra línea más. Esto es más grave que unos cuantos caracteres repetidos. Hay que pararse a pensar de nuevo, es hora de ganarse el sueldo. Lo que se me ocurrió es lo siguiente:

class Fixnum
	ARABIC_TO_ROMAN_NUMERAL = { 10 => 'X', 5 => 'V', 1 => 'I' }

	def to_roman
		return ARABIC_TO_ROMAN_NUMERAL[self] if ARABIC_TO_ROMAN_NUMERAL[self]
		ARABIC_TO_ROMAN_NUMERAL.each do | arabic_number, roman_numeral |
			return roman_numeral + (self - arabic_number).to_roman if self > arabic_number
		end
	end
end
#  .............

La idea es recorrer la colección de numerales, de forma que encontremos el numeral romano de más valor, que sea inferior al número que buscamos, y usamos dicho numeral en la regla recursiva que descubrimos antes para calcular el resultado. Podríamos haber usado un bucle for, pero sospecho que no están bien vistos en el mundo de Ruby, así que uso el método iterador each, y le paso un bloque de código. En cuanto encuentro el numeral buscado devuelvo el valor y el bucle (perdón, la iteración) termina. De paso ya no necesito ese método auxiliar que se me ocurrió antes, ya que la regla recursiva sólo se usa una vez y es bastante compacta. Me encanta cuando los planes salen bien… WTF! ¡ Fallan los tests ! ¡ Qué c*** pasa ! ¡ Es la hora del debugger !

Lo que ocurre es que el método each itera las entradas de la hash en el orden que le sale de las gónadas. Es una sorpresa, ya que según la documentación, debería iterarlos en el orden en que los añades a la hash. Ya estoy por mandar un bug a la comunidad de Ruby cuando descubro mi fallo. Estoy usando Ruby 1.8.x y la documentación es de la 1.9.x. Algo huele a quemado, busco un poco y efectivamente: originalmente el orden de iteración de las hash era aleatorio, pero a partir de la 1.9.x es por orden de inserción. Esto de añadir cambios que rompen la API y cambiar sólo el “minor version” no es buena idea.

Total, que tengo una implementación que supuestamente funciona en Ruby 1.9 (no lo he probado), pero no en 1.8. Algo he de hacer. De momento me calmo un poco, y me dedico a arreglar otra duplicación de código que me está matando, la primera línea del método to_roman. Lo que hago es lo siguiente:

class Fixnum
	ARABIC_TO_ROMAN_NUMERAL = { 10 => 'X', 5 => 'V', 1 => 'I' }

	def to_roman
		return '' if self == 0
		ARABIC_TO_ROMAN_NUMERAL.each do | arabic_number, roman_numeral |
			return roman_numeral + (self - arabic_number).to_roman if self >= arabic_number
		end
	end
end
# ..............

Directamente elimino la línea y cambio self>arabic_number por self>=arabic_number. La idea es que si encuentro un numeral que sea exactamente igual al valor buscado, también puedo aplicar la regla recursiva. En este caso el resto es 0, que como sabemos no se representa en números romanos. Se soluciona devolviendo cadena vacía como caso base de la recursividad cuando el número es 0, eliminando la fea duplicación que teníamos como caso base.

Ahora ya puedo centrarme en hacerlo retrocompatible con Ruby 1.8. Simplemente ordeno de forma explícita la hash en orden descendiente (de mayor a menor). Un cambio trivial:

class Fixnum
	ARABIC_TO_ROMAN_NUMERAL = { 10 => 'X', 5 => 'V', 1 => 'I' }.sort.reverse

# ................

end

Dicho sea de paso, esta ordenación me devuelve un array, con lo que en vez de una hash termino con un array de pares clave/valor en la constante ARABIC_TO_ROMAN_NUMERAL. Debido a que itero con el método each, y a que realmente había dejado de usar la búsqueda por clave, el cambio es transparente.

Ahora toca enfrentarse a la tercera fase de la especificación funcional: los casos especiales. Los romanos no escribían ‘IIII’ para el número 4, sino ‘IV’. Lo mismo con el 9 que se representa como ‘IX’ en vez de ‘VIIII’ (esta regla es para los números romanos clásicos, la versión más primitiva no la tenía). Añado estos ejemplos y obviamente los tests fallan. Tal vez tenga que hacer un algoritmo de simplificación, de modo que si hay tres numerales seguidos iguales los sustituya por la versión simplificada. Parece difícil. Antes de complicarme la vida, y por si cuela, se me ocurre añadir ‘IX’ y ‘IV’ a los numerales básicos. Sorprendentemente funciona, me olvido de algoritmos complicados. Finalmente añado algunos tests con números complicados, para asegurarme que todo funciona bien. El código final es:

class Fixnum
	ARABIC_TO_ROMAN_NUMERAL = { 10 => 'X', 9 => 'IX', 5 => 'V', 4 => 'IV', 1 => 'I' }.sort.reverse

	def to_roman
		return '' if self == 0
		ARABIC_TO_ROMAN_NUMERAL.each do | arabic_number, roman_numeral |
			return roman_numeral + (self - arabic_number).to_roman if self >= arabic_number
		end
	end
end

describe "Roman number" do
	context "has basic numerals with different values" do
		it "I is equivalent to 1" do
			1.to_roman.should == 'I'
		end

		it "IV is equivalent to 4" do
			4.to_roman.should == 'IV'
		end

		it "V is equivalent to 5" do
			5.to_roman.should == 'V'
		end

		it "IX is equivalent to 9" do
			9.to_roman.should == 'IX'
		end

		it "X is equivalent to 10" do
			10.to_roman.should == 'X'
		end
	end

	context "concatenates numerals in descending order until they sum up the desired integer" do
		it "II is equivalent to 2" do
			2.to_roman.should == 'II'
		end

		it "III is equivalent to 3" do
			3.to_roman.should == 'III'
		end

		it "VI is equivalent to 6" do
			6.to_roman.should == 'VI'
		end

		it "XI is equivalent to 11" do
			11.to_roman.should == 'XI'
		end

		it "XV is equivalent to 15" do
			15.to_roman.should == 'XV'
		end

		it "XX is equivalent to 20" do
			20.to_roman.should == 'XX'
		end
	end

	context "converts even complex examples (to gain more trust in our implementation)" do
		it "XVIII is equivalent to 18" do
			18.to_roman.should == 'XVIII'
		end

		it "XIX is equivalent to 19" do
			19.to_roman.should == 'XIX'
		end

		it "XXXVII is equivalent to 37" do
			37.to_roman.should == 'XXXVII'
		end
	end
end

Como veis el código es diferente al que propuso @ecomba. Curiosamente @ialcazar me mostró la solución de @cavalle que es bastante similar a la mía, seguramente porque ambos hemos optado por un enfoque recursivo. Eso sí, ninguna de las tres soluciones tiene métodos de más de 4 líneas de código . Notad que he tomado dos decisiones de diseño importantes: me he decidido por un diseño recursivo, y los casos especiales, como ‘IV’ o ‘IX’, los trato como numerales básicos. ¿Qué ocurriría si hubiéramos decidido que los casos especiales no son numerales básicos? ¿A alguien le interesa explorar este camino?

¿Para que nos ha servido el TDD? En este caso nos ha servido para guiar el proceso de pensamiento. Añadiendo código poco a poco puedo detectar duplicación, violaciones de principios SOLID, y otros problemas rápidamente. Es en estos momentos donde TDD+Refactor en pasos pequeños, nos obliga a parar y pensar. Hasta que no tengamos una visión más profunda del problema, no podremos avanzar, y ésta forma de trabajar nos golpea en la cabeza obligándonos a reflexionar. Sin embargo no olvidemos que el problema de los números romanos es pura algorítmica. En casos más complejos como diseño OO el TDD brilla en todo su esplendor.

Si queréis, podéis entrar github y echarle un vistazo a todo el histórico de “baby steps” que fui haciendo. ¿Alguien se anima a hacerlo en otro lenguaje?