Logra una Migración del Legacy Exitosa: Consejos Clave 🚀
Vložit
- čas přidán 16. 08. 2023
- En la mayoría de empresas el mayor reto que suele haber es migrar de un sistema legacy a uno nuevo. Pero muchas veces se queda en un intento a medias, pasan los años y ese nuevo sistema se vuelve también legacy. En el vídeo de hoy vamos a ver cómo evitar esto.
Primeras lecciones gratis del curso de Grafana! → bit.ly/grafana-codely
﹤🍍﹥ CodelyTV
├ 🎥 Suscríbete: czcams.com/users/CodelyTV?sub_co...
├ 🐦 Twitter CodelyTV: / codelytv
├ 🎩 Twitter Joan: / joanjan14
├ 💂♀️ Twitter Rafa: / rafaoe
├ 📸 Instagram: / codelytv
├ ℹ️ LinkedIn: / codelytv
├ 🥋 Academy: codely.com/academy
└ 📕 Catálogo cursos: bit.ly/cursos-codely - Věda a technologie
Hola buenos temas! Me interesa el Refactory entre la Query y quizás métodos de controlador. A veces la lógica esta repartida entre el stored procedure y un código de la app. Y encima puede llegar a reutilizarse partes. Pero el problema que por rendimiento y alguna facilidad ese código esta en la base de datos.
No se puede hacer 999999 en z-index ahh pero en back aqui esta jajajajajaja 😇
Si se puede pero shihhh no reveles tecnicas senior 😊
Hola una consulta que opinas de fluent pdo se usa en muchos framework para consultas MySQLi
que genios
esa te permite identificar las old query que se están utilizando no?
Entonces lo que propones es modificar todas las querys del sistema legacy para luego analizar los logs?
Alguien sabe si existen patrones o formas de poder escribir nuevamente esa "raw query" en el nuevo backend? estoy exactamente en la misma situación que la del video jaja, ayuda D:
😮 y como a Juana de arco.... La ayuda no llego y fue capturada y quemada en la hoguera 😕 todo es culpa de los franceses y María Antonieta
Muy bueno, pero no entiendo una cosa, quizas peco de ignorante...pero si partimos de la base de q seguro tenemos querys acopladas digamos, esos gigantes q son una query para hacer mil cosas...kizas en el sistema nuevo sea mas funcionalidad en codigo y seguramente mas querys (mas chicas) para la misma funcionalidad...o sea parto de esta base. AHORA, si el porcentaje de avance es sobre uso de unidades de querys nuevo vs viejo....kizas ese porcentaje sobre el 100 mezclado me de avances de saltos muy grandes q pueden llegar a sentir q avanzamos un monton.....y en realidad migramos 1 gigante acoplado....q muy bien, pero ese poco porcentaje de desaparecer va a costar mucho subir si son muchas querys asi de grandes....o sea dejo de usar 1 query en el sistema viejo y de repente uso 5 en el sistema nuevo...para la misma funcionalidad....ENTONS, se me ocurre mientras escribo , esto ke kizas es un delirio...pero ahi va
...conseguir el total de querys existentes en el sistema viejo....y dejarlo como constante xq kiero creer q como sistema legacy no le vamos a sumar nuevas je..
Entonces un porcentaje de avance en la migracion puede ser el % de uso de querys de sistema viejo sobre el total existentes inicial en el sistema viejo(xq se pueden ir borrando) ...que ira decreciendo.... Saludos!
Creo que no es buen enfoque y tiene un porqué, ellos sugieren ese sistema por qué habrá queries grandes o pequeñas que no se usen, y alguna que se use una barbaridad, si una query que se repite mucho la migras, avanzaras mucho, y si migras una que no se usa, no avanzas nada
@@lacorz93 claro totalmente eso, y esta claro q el emfoque esta en descubrir q ya no se usa y si se usa. pero mi hipótesis es q una query vieja acoplada en una migración te va a traer más de una query en el nuevo, x eso sugiero el cambio en la cuenta de relación de avance, para dejar como constante de relación el total de query del sistema legacy. Gracias x leer jeje
Yo quiero ver más porque no es comprable el curso sino solo por suscripción 😢