El pasado sábado tuve la oportunidad de efectuar un viaje relámpago para acudir a mi primer Bilbostack un evento que reunía a grandes profesionales de la talla de Rodrigo Corral, Vicenç García, David Bonilla, Ibon Landa o Alfredo Fernández para discutir de temas técnicos y no tan técnicos. Aquí va pues, mi breve resumen. Es importante destacar que había 2 tracks en paralelo, así que aquí va mi resumen de medio evento ;) :
BDD por Vicenç García
Una charla muy interesante donde vimos el concepto de «behaviour-driven development», ideado por Dan North hace ya unos años. El desarrollo dirigido por comportamiento comienza por los test, donde se prueba un escenario concreto, usando el propio lenguaje de negocio, con lo cual nos permite saber, a nivel de funcionalidad, qué estamos probando exactamente.
El hecho de usar un lenguaje específico como gherkin permite que los analistas de negocio especifiquen los requisitos usando su propio lenguaje, que desarrollo pueda convertir esos requisitos en ejecutables, y que el equipo de QA pueda validar de manera automática dichos requisitos, nos permite tener una batería de test de regresión, que nos permiten saber si hemos roto algo al agregar nueva funcionalidad. Como herramientas, para .NET se puede desarrollar con Specflow
Mosqueteros, por «La personalité» (Ana Malagón y Goio Telletxea)
Qué pasa cuando pones a diseñadores y artistas gráficos en una charla con programadores? Pues que salen ideas interesantes, desde la industrialización del trabajo de diseñador, donde herramientas como Bootstrap o Foundation aceleran trabajo pero logran que todo sea demasiado homogéneo, hasta cómo el diseñador se atreve a tocar algo de código y el desarrollador empieza a apreciar y adquirir cierto gusto estético, cómo han pasado a automatizar tareas repetitivas para poder dedicarse a las tareas importantes, el concepto de guía de estilo aplicada al diseño, y el hecho de que.
Todos nos dedicamos a diseñar
Deja de decir que en tu máquina compila, por Bea Martín y José Rubio
Entré en esta charla pensando que veríamos temas de integración continua, pero fue más bien una charla que se podría titular «No seas más capullo de lo necesario» o «Deja de quejarte». Con estas premisas, la cosa prometía… La charla estaba dividida en varias secciones: Compartir el conocimiento, trabajar en equipo, ser honesto, cuestionarnos lo que hacemos, ser conscientes de que si el contexto es una empresa, no somos ajenos a ello, y mejorar continuamente.
En ellas, se discutieron cosas como que la queja es contagiosa y nociva, que tenemos la obligación de transmitir nuestros conocimientos, que hemos de hacer que las máquinas entiendan a las personas, y no al revés, no hacer «estimaciones optimistas» que suelen llevar a engaño, tener pensamiento crítico (sobre todo con uno mismo), saber el impacto de lo positivo de la empresa, y de lo negativo de le queja, y finalmente, que nada es para siempre. No debemos dejar de jugar, de aprender, de mejorar, y hemos de ser conscientes de que el mundo ha cambiado, ya no estamos toda una vida en una única empresa.
Me quedo con la frase:
Es tan poco lo que se puede hacer, que todo lo que pueda ser, sea.
Deuda técnica por Rodrigo Corral, cómo refactorizar una favela?
Tras perder a un ponente por el camino llegó Rodrigo como plan B para hablarnos de Deuda técnica. Básicamente se reduce a que si no mantenemos cierta calidad en el código, el coste de arreglar un bug se hace exponencial, y que reducir la calidad alarga el tiempo de desarrollo. La deuda técnica es aquello que está «mal» implementado en el código, desde el punto de vista de rendimiento, buenas prácticas, etc (la ñapa clásica), y que ha de arreglarse, ya sea refactorizando o reescribiendo una parte del código.
Lo importante para poder gestionarlo es, en primer lugar, ser conscientes de que existe, de cuanta hay (usando herramientas como FxCop o las herramientas web de google, si desarrollamos aplicaciones web). Finalmente, para poder ser lo más efectivos posibles hemos de considerar el retorno de inversión (ROI) a la hora de arreglar deuda técnica, ya que en principio perderemos tiempo y recursos, que se compensarán en el futuro. Lo importante es poder estimar si el coste es asumible. Todo el código nace con problemas que solamente se resuelven en producción.
Para pagar la deuda técnica, primero debemos aprender (y un montón), luego tener diplomacia (ese código lo ha escrito alguien, en el mejor de los casos, tú), intentar conseguir una arquitectura identificable, no romper nada, perseverar y asegurarse que hay resultados visibles, entre otras cosas, para poder justificar el tiempo empleado en las correcciones.
Por otro lado la mejor manera de resolver deuda técnica es no generandola, tener principios y no renunciar a ellos, construir una ética profesional, recurrir a referencias como Clean Code o The art of UNIX Programming, usar principios SOLID si trabajamos en orientación a objetos, y otros tantos ejemplos de cómo hacer código mantenible y limpio. La frase de «Cómo refactorizamos una favela» ilustra cómo acaba un proyecto que empieza sin una estructura clara, siendo la única manera viable reescribir una buena parte.
El paso al lado oscuro de David Bonilla
No, David no se ha pasado a .NET, aún. En esta charla nos comentaba su experiencia de cómo pasó de programador a una persona de «negocio» como parte de Otogami, su comparador de videojuegos, qué tipo de problemas te enfrentas, cómo te pegas la «hostia» contra el suelo cuando tus cálculos te fallan y cómo se han ido adaptando a las condiciones que ofrece el mercado. Usando sus propios datos como ejemplo al más puro estilo Bonilla, nos habló de lo que nadie te habla en internet: Tiempo, Tecnología y Tráfico, las cosas llevan mucho tiempo en hacer, la tecnología da igual mientras no de problemas, y conseguir tráfico es prácticamente imposible. Además, dada la reciente inversión que se ha cerrado en su empresa, nos contaba por qué necesitaban el dinero, y cuales eran los planes de cara al futuro.
También nos contó su frustración ya que uno de los mayores problemas con los que se habían encontrado era la falta de información, y por ello, continuando con una cruzada empezada hace unos años, hizo un llamamiento a empresas para compartir datos entre ellas, como por ejemplo las analíticas de Google, que pudieran ser útiles para todos.
Conclusiones
En general un evento de 10 para la organización, el sitio relativamente cómodo (para los que venimos desde fuera se nos hace difícil valorar la ubicación) y, aunque el clima no acompañó, una grata experiencia por encima de todo.
Otros puntos de vista
Otros asistentes también han dejado constancia del evento en sus respectivos blogs, aquí dejo algunos enlaces:
rlbisbe @ dev 