Día de Open

Ayer celebramos el #devopenmadrid, que fue un nuevo Open Space, aunque más enfocado al desarrollo.

La idea, si no me equivoco, surgió en la retrospectiva del AOS2010, donde una de las cosas que se dijo fue que se habían echado en falta temas técnicos y se pensó la idea de que quizás se podrían hacer más eventos de ese estilo sin necesidad de estar meses organizándolo ni pensarlo para que sea algo para 200 o 300 personas. Así que dicho y hecho, Jesús Jiménez se puso manos a la obra y demostró que no hace falta mucho para organizarlo, buscó un sitio en el que poder juntarnos y no se buscó ni patrocinadores ni nada, total, ¡qué son 15 euros para cada uno de nosotros!¡Gracias por el esfuerzo!

Fuimos llegando tempranito para poder aprovechar el día.

La asistencia no estuvo nada mal porque al final fuimos unos 50 asistentes y en cuanto estuvimos todos empezamos a proponer temas. En esta ocasión creo que estuvimos más moderados a la hora de proponer y no salieron demasiados temas, pero aún así hubo mucho donde elegir durante todo el día.

El tablón inicial quedó creado, pero como aún quedaban algunos huecos contando como sitios de reunión el pasillo, la cocina, la cafetería de al lado o cualquier otro sitio que se nos ocurriera se dejó abierto para que si a alguien se le ocurría algún tema nuevo fuera libre de añadirlo al tablón. Esta vez, guiados por el consejo de Enrique Comba, no hicimos ninguna votación ni nada para así empezar más rápido, simplemente pusimos todas las charlas que fueron saliendo en el tablón y si luego hacía falta cambiar alguna de sala por la afluencia de gente se cambiaba y punto.

¡Y comenzamos!

La primera charla en la que me metí se titulaba “Doctor, Doctor… Modelo Anémico” y había sido propuesta por Kinisoftware y Jacegu.

En ella inicialmente se dio una definición simple y directa sobre qué es un modelo anémico: tener objetos del dominio con únicamente métodos getters y setters, sin más lógica, únicamente contenedores de datos. Empezamos a discutir por qué este modelo de datos no es bueno y se mostraron unos cuantos argumentos:

• Te cargas la encapsulación (¿de qué te sirve tener las propiedades de esa clase privadas si realmente las estás haciendo públicas con los getters y setters?).
• Estás usando clases como estructuras.
• Estás creando una capa de contenedores de datos y otra capa para actuar sobre esos objetos, poniendo la lógica de negocio lejos de los datos.

¿Y qué tenemos que hacer para buscar tener un modelo bueno? Pues por ejemplo seguir los consejos del “Tell, Don’t Ask” y la Ley de Demeter para decir a los objetos que hagan cosas en lugar de preguntarle a los objetos por elementos de su estado interno.

Un ejemplo gracioso respecto a esto que propuso Alfredo Casado es que si vas a pagar la compra en una caja no le das al cajero tu cartera para que el cajero saque el dinero de ella, sino que le das directamente el dinero, de igual forma nuestros objetos debería encargarse de dar la información necesaria, no de dar otros elementos para que otro desde fuera sea quien tenga que obtener la información.

Respecto a esto alguien preguntó que por qué el getter era malo y la respuesta fue simple: el getter no es malo, lo malo es usarlo para exponer los atributos internos de una clase para que alguien desde fuera opere.

Pero un problema que nos encontramos cuando intentamos evitar modelos anémicos es que podemos acabar creando objetos demasiado grandes y con demasiada responsabilidad y la única solución que hay es estar en contacto con el cliente todo lo posible para encontrar un buen diseño del dominio y para ir buscando objetos pequeños que respondan a preguntas pequeñas en lugar de tener un objeto que responda a todas tus preguntas.

¡Es duro pero hay que intentar ponerlo en práctica!

La siguiente charla en la que estuve fue “Mockear” propuesta por Emma.

En esta charla partíamos de la pregunta de si era buena realizar tests con mocks o no. Al principio no entendimos bien de dónde surgía la duda hasta que empezamos a aclarar algunos términos y es que antes de pensar si mockear o no tuvimos que explicar un poco algunos términos de los distintos tipos de dobles de objetos que algunos no estábamos viendo como diferentes pero que en el planteamiento de la charla sí eran diferentes:

• Stub: Permite manejar los resultados esperados en las llamadas a un objeto.
• Mock: Doble de un objeto que permite definir las llamadas que se esperan se produzcan sobre el objeto. Se tienen que definir las llamadas esperadas antes de la llamada que se está probando y luego las verificaciones en la zona de comprobaciones. Además, si se realiza una llamada sobre el doble que no se encuentra definida entre las esperadas el test falla.
• Spy: Es el doble de un objeto que almacena las llamadas realizadas a métodos de este objeto para poder verificar en la zona de comprobaciones si se han realizado las llamadas deseadas. Cuando se producen llamadas a métodos no esperados no falla el test y si devuelve algo el método, se devuelve un valor por defecto(por ejemplo null).

¿Y cuándo usar cada uno? Pues todo depende del problema al que te enfrentes, si quieres probar a qué métodos se llama asegurándote de que no se produce ninguna llamada más de las que estás comprobando, si sólo quieres asegurarte de que una llamada se realiza sin importarte si se hacen más llamdas o si quieres asegurar que un objeto devuelva un resultado.

Además hay que tener en cuenta que en los tests con mocks, stubs o spies el test queda acoplado al código, ya que si cambian las llamadas que estás haciendo el test puede fallar. Por ello, estos objetos dobles pueden servir para diseñar el código y olvidarte de una parte con la que tienes que integrar el código y que no depende de ti, pero es peligroso usarlos sin control ya que puedes caer en crear demasiados colaboradores dentro del código.

También hay veces que te puede interesar no recurrir a estos dobles de objetos, sino crearte tú tu propio doble del objeto que quieras probar, incluso es una técnica necesaria cuando quieres probar algunos métodos que los dobles no te dejan como el “toString”.

Así que la conclusión de esta reunión yo creo que fue que tienes que usar cada herramienta cuando realmente la necesites, no usar una siempre por el hecho de haberla aprendido y también que el mejor momento para usar estos dobles es antes de hacer el código puesto que si los escribes después es muy posible que hagas un test totalmente acoplado al código escrito que replique las llamadas realizadas en el código.

La siguiente charla en la que me metí fue “Código Expresivo” propuesta también por Kinisoftware y Jacegu, que llevaban tiempo hablándolo con Alberto Peña a quien al final la gripe le tuvo en cama gran parte del día.

La idea de esta charla era hablar un poco sobre el Clean Code, un libro que muchos consideran que debería darse a un programador nada más aprender a programar.

Uno de los puntos importantes que se tratan es sobre el “naming”. Es importante enseñar a nombrar las cosas desde el principio ya que si no eres capaz de ponerle nombre a algo es porque realmente no sabes lo que hace.

Pero si estás implementando en una clase un patrón de diseño, ¿deberías indicarlo en el nombre de la clase? Aquí hubo algo de discusión, ya que aunque en el libro se hace, quizás puede llevar a poner nombres que no sean realmente significativos para el dominio.

¿Y cómo de largos deberían ser los nombres? Lo mejor es buscar un equilibrio entre la longitud del nombre y que sea suficientemente expresivo y sobre todo tener en cuenta que si aparecen cosas como “y” u “o” en los nombres hay que repartir responsabilidades. En el libro se autoimpone una restricción de 120 caracteres para evitar tener nombres demasiado largos que pasen a ser ilegibles.

¿Y cómo se manejan los distintos niveles de abstracción con la legibilidad del código en un lenguaje natural? Está claro que escribiendo código tiene que haber código y que hay partes del código que al final tienen que tener nuestros algoritmos, lo importante es que en cada nivel de abstracción tengas un nivel homogéneo de información de forma que que se pueda leer de forma horizontal y cuando un usuario que esté leyendo el código quiera más información sobre una parte en concreto pueda navegar de forma vertical para ir encontrando una información más específica. Por ejemplo no sería coherente un código que fuera:

if (x + y == 4 && esDivisiblePorDos(x))

También tuvimos mucho en lo que entrar en materia cuando empezamos a hablar sobre el tema de excepciones, las cuales siempre deberían usarse para tratar casos excepcionales y no para controlar el flujo de una aplicación, aunque se acabó el tiempo y no tratarlo tanto como nos habría gustado.

En la siguiente hora me quería meter en una propuesta de Germán que me pareció muy interesante sobre programar unos robots para hacer una guerra de robots. Lo malo es que cuando llegué a la sala ya estaba bastante llena y no vi mucho sitio para meterme con mi ordenador y desistí, además fuera me encontré con gente con la que tenía ganas de charlar aprovechando la oportunidad de juntarnos y se nos fue la hora volando (¡en estos eventos es difícil no liarte hablando con la gente!)

Pero en la última sesión tenía claro que quería ver un poco de Clojure, así que me metí en la sesión “Clojure Koans“.

En esta sesión nos pusimos manos a la obra con más ganas que experiencia a experimentar con las Clojure Koans utilizando el formato de randori. Aunque sólo nos dio tiempo de hacer unas cuantas estuvo bastante bien como toma de contacto con Clojure, ya que para mí que vengo principalmente de lenguajes con orientación a objetos un primer vistazo a Clojure asusta jeje.

Después de las charlas hicimos una pequeña retrospectiva en la que valoramos el esfuerzo de Jesús para organizar todo y por demostrar que no hay que organizar mucho para hacer un evento de este tipo, algunas personas lamentaban que no se hubiera programado más, mientras que a otras les pareció positivo haber podido hablar y discutir sobre temas técnicos y hubo también discrepancias con si empezar temprano había sido buena o mala idea, pero qué se le va a hacer, nunca llueve a gusto de todos.

Fue un día como siempre divertido e instructivo, como no puede ser de otra forma cuando estás rodeada de gente que tiene tanto para enseñar y compartir. Hubo gente nueva que no había asistido antes a eventos de este tipo y eso es bueno porque quiere decir que la comunidad ágil crece y los desarrolladores preocupados por su profesión aumentan. Lo que sentí fue la poca participación femenina, ya que sólo estábamos 4 chicas y ninguna cara nueva, todas ya integrantes de las Agile-Girls, ¡habrá que predicar más!