deuda técnica

Ponente: Joaquín Engelmo Llevo varios años trabajando con [micro]servicios en Tuenti y quiero contar mi historia. Además no hace mucho tuve la suerte de asistir a un evento, From The Trenches donde pude aprender, recopilar y reafirmar algunas cosas relacionadas con este tema tan en boca de todos. De ahí el nombre de la charla. El espíritu de la misma es enseñar, desde una base teórica inicial a modo de introducción, el camino que seguimos nosotros para evolucionar toda una base de código hacía este paradigma y, de forma práctica, ver como estamos a día de hoy. Como soy de los que piensa que el código no lo es todo, también hablaré de equipos, componentes, responsabilidades, etc. y verás que está todo relacionado con los [micro]servicios. También me gusta ensuciarme las manos y enseñar "cosas reales" como herramientas de monitorización o contar como va todo nuestro workflow, desde picar el código hasta sacarlo a producción usando Docker y Kubernetes. Mundo real, problemas reales, soluciones reales y en producción durante años que dan servicio a millones de clientes. No serán los [micro]servicios más "artesanos" del mundo, y tampoco somos Netflix, pero hacen su función, controlando deuda técnica y tomando decisiones pragmáticas - siempre que se puede -. Motivación, partiendo el monolito, arquitectura, prácticas, testing, despliegues, monitoring, alarmas, etc. Pros vs Cons desde la experiencia en una base de código grande, bastantes [micro]servicios, un monolito y millones de usuarios potenciales.

El código mal hecho y la deuda técnica se asemeja a los zombies: nunca muere, corrompe, nos da miedo modificarlo... Mediante los test y la práctica de TDD, podemos vencerles. Todos los videos de WTM Madrid https://www.youtube.com/playlist?list=PLKxa4AIfm4pXjz3_wZQZwX-r44qsQH0i4 Suscríbete a nuestra newsletter; https://goo.gl/5jc6uP Facebook; https://goo.gl/o8HrWX Twitter; https://goo.gl/MU5pUQ LinkedIn https://goo.gl/2On7Fj/

"Llevo unos 3 años trabajando con [micro]servicios en Tuenti y quiero contar mi historia. Como toda buena historia de [micro]servicios tiene un inicio con un diabólico monolito y una campaña por hacerle frente rompiéndolo. La parte central de nuestra historia tendrá elementos de batalla épica, tipos de armas que usamos, estrategias de creación de ejércitos y un sin fin de anécdotas. El final, que presentará la historia a día de hoy, ya os aviso que no será feliz pero tampoco será triste. Si esta gran metáfora no ha sido suficiente para convencerte de ver mi charla te lo digo con otras palabras: Mundo real, problemas reales, soluciones reales y en producción durante años que dan servicio a casi un millón de clientes. No serán los [micro]servicios más "artesanos" del mundo pero hacen su función, controlando deuda técnica y tomando decisiones pragmáticas. Motivación, partiendo el monolito, arquitectura, prácticas, testing, despliegues, monitoring, alarmas, etc. Pros vs Cons desde la experiencia en una base de código grande, bastantes [micro]servicios, un monolito y 1M de usuarios potenciales. Y, por si aún no te lo habían contado, no sólo es código sino también equipos, componentes, responsabilidades, etc. ¿Te he convencido ahora? :)" Todos los videos de Pamplona Software Craftsmanship https://www.youtube.com/playlist?list=PLKxa4AIfm4pWzA2ILUMUDwD_0QGIIJetn Descarga gratis la versión digital del libro de Roberto Canales “Conversaciones con CEOs y CIOs sobre Transformación Digital y Metodologías Ágiles ” https://goo.gl/i2zZtJ Suscríbete a nuestra newsletter; https://goo.gl/5jc6uP Facebook; https://goo.gl/o8HrWX Twitter; https://goo.gl/MU5pUQ LinkedIn https://goo.gl/2On7Fj/

Iniciativa para solucionar problemas relacionados con la deuda técnica, interrupciones, y ciertas dinámicas de trabajo. Por Luis Rovirosa.

Partimos de un reto: cómo cambiar una web con millones de visitas, con un entorno en constante cambio, con una deuda técnica crítica y un equipo aumentando en número, en procesos para la generación de software de manera automatizada, documentada, probada y coordinada para la consecución de nuestras metas. En esta charla se presenta el caso práctico de la implantación de Symfony como pieza fundamental del puzzle y la integración continua como camino a seguir. Pruebas, integración, bundles, bases de datos, rendimiento... Aspectos claves para la consecución de nuestros objetivos.

Siguiendo con el tema de las prácticas y métodos que nos funcionan como equipo, voy a intentar describir la experiencia que hemos tenido en los últimos casi 4 años en el equipo de producto en Alea Soluciones creando desde cero un equipo ágil con una cultura fuerte y usando XP.¿De donde partíamos?Partíamos de una situación precaria en la que por diversos motivos no existía equipo de desarrollo y producto. Sólo quedaba yo y casi de forma casual. ¿Cual era el camino?Crear un equipo á...

Por todos lados dicen que un programador muy bueno puede ser hasta 10 veces más productivo que uno malo...Yo creo que la relación no es exactamente así sino que uno bueno puede ser dos o tres veces más productivo que uno normal y uno malo, en realidad no es que tenga una productividad muy baja o nula, sino que genera más deuda técnica y problemas del valor que aporta (código de muy mala calidad, muchos bugs, diseños malos y no entendibles).Normalmente no nos atrevemos a decirlo, pero hay gente q...

Desde siempre he tenido claro que en desarrollo es muy importante que cada concepto este una sola parte del sistema. Por otro lado, también tengo muy presente que la duplicidad de código es un problema y que hay que intentar limitarla y en los casos que sea necesario (casi todos) eliminarla sistemáticamente.Muchas veces se sigue el concepto DRY a ciegas, sin tener en cuenta que cada decisión tiene un coste, por lo que voy a exponer algunos puntos que pueden ayudar a decidir cuando debemos elimin...

La calidad es el cumplimiento de las expectativas del usuario teniendo en cuenta que además: – Una deuda técnica acorde al contexto en el que se ha desarrollado. – Una tasa de errores y un grado de acabado de los requisitos no funcionales como por ejemplo rendimiento y seguridad en función de las características del …Leer Más - por Jummp

Su enunciado es el siguiente: “Cuando un sistema evoluciona se incrementa su complejidad a menos que se trabaje para mantenerla o reducirla”. La complejidad crece no solo a nivel de deuda técnica (algo que es razonable por el incremento del tamaño del sistema), sino también a nivel de administración, usabilidad y recursos software y hardware …Leer Más - por Jummp