Conforme más viejo me hago, menos me importan las nuevas tecnologías.
Quizás es un poco una fase depresiva en la que estoy, o que me estoy haciendo viejo y cada vez tengo menos paciencia por las cosas.
Pero es que me importan a un pepino las nuevas tecnologías.
Estoy intentando pasar la actualización de Next12 a Next13 y no es trabajo divertido de una aplicación en producción.
Y además de todo esto, el nuevo concepto de app en Next, que no me importa.
O sea, I just don't care.
He adoptado Turbo Repo y se arrepiente por 10.
Quiero construir cosas para la gente.
No estar constantemente actualizando mis herramientas porque otros desarrolladores están aburridos.
La verdad es que estoy muy de acuerdo. Estoy bastante de acuerdo. Me gusta mucho esto.
Muchas veces se nos pasa este... No sé, se nos olvida que realmente estamos construyendo cosas para la gente.
Next12, sinceramente, Next12, la versión 12 de Next, va a ser todavía útil.
Next12 durante mucho tiempo. No hay una necesidad imperante a no ser que tengas un problema de rendimiento y te lo solucione Next13.
Next12 durante mucho tiempo va a seguir funcionando perfectamente.
A no ser que Next13, por una ventaja competitiva, algo que no puedas hacer, a lo mejor no lo necesitas.
Pero también es verdad, y yo creo que es un poco un error también de lo que le pasa a esta persona respecto a esta actualización.
Tampoco es necesario... O sea, si hubiera actualizado a Next13, puede seguir utilizando el concepto antiguo.
Y eso es una de las cosas que os voy a dejar para que si tenéis que aprender algo hoy, os voy a dejar una frase de Guillermo que se nota que el tío sabe de lo que habla.
Hay dos tipos de migraciones en el mundo del desarrollo, las incrementales y las que se fallan.
Eso es una verdad astronómica en el mundo de la programación.
Y os voy a explicar por qué muchas veces esto es verdad.
Por ejemplo, imagínate que tú tienes una página web antigua con muchas páginas, un millón de usuarios,
pero claro, está hecho en un monolito con .NET, el código no es que sea .NET, pero a lo mejor es muy antiguo, tiene jQuery y quieres migrar a React.
He visto así de migraciones fallidas por intentar hacerlo de golpe.
Por ejemplo, intentar vamos a parar producción y a los tres meses sacamos la nueva página.
Eso no funciona nunca. Siempre, siempre, siempre las migraciones tienen que ser incrementales.
Tienes que intentar parar las cosas que sean lo más transparentes posibles en pequeños cambios iterativos.
Y esto en el mundo del desarrollo del software es vital, vital.
Y esto, que lo tiene muy claro Guillermo, lo hace muy bien en NextGS.
¿Y por qué lo hace muy bien en NextGS? Porque en NextGS 13, os puede gustar más o menos el tema de AppRouter y todo esto,
pero sigue funcionando casi todo lo de Next12.
O sea, no estás obligado a pasar al AppRouter.
Y lo que es mejor, si lo hacéis, podéis ir de forma incremental, ir pasando ruta a ruta.
Y eso, eso muy, muy, muy, muy bien por Guillermo porque se nota ahí que el tío sabe de lo suyo.
Os recomiendo mucho este artículo porque este artículo muchas veces hablamos de la ingeniería del software y que no solo es código.
Y este artículo, os lo juro, es una joya.
Me encanta porque yo esto lo he vivido, ¿ves?
Migrando desde un monolito a una arquitectura Composable, ¿no?
Muy chula porque se puede hacer, por ejemplo, migraciones a través del tráfico con proxys.
Las rutas, por ejemplo, en lugar de hacer toda una página, puedes hacer un trozo, un widget,
o puedes hacer una ruta y puedes hacer que solo un 1% de los usuarios vaya a la ruta nueva para probar que funciona bien.
Y el 99% vaya al otro lado, que esto es lo que se le llama un lanzamiento oscuro.
Bueno, hay diferentes, ¿no?
Gente le llama b-testing, lanzamiento oscuro, canary, release, hay un montón de cosas.
Pero, de verdad, si queréis aprender de cómo funcionan realmente productos de software bien hechos en el mundo real,
este artículo está muy bien escrito y es que estoy de acuerdo al 180%.
¿Veis? Aquí tenéis, por ejemplo, el usuario a usuario, ¿no?
Y lo vas incrementando.
Esto sería una optimizely progressive delivery, ¿vale?
Que poco a poco lo que vas haciendo es eso, ¿no?
Es decirle, vale, pues poco a poco lo vas subiendo.
Eso es lo que no te enseñan los bootcamps.
No, hombre, a ver, si esto lo enseñan los bootcamps, la verdad es que Q2 para los bootcamps porque es increíble.
O sea, es mucho.
Pero es verdad que este tipo de cosas, por desgracia, nadie las comenta, nadie le importa.
Mira, esto con un reverse proxy, esto lo he llegado a hacer yo.
Y eso se nota mucho en Next.js, que lo hacen un montón.
Total, este comentario estoy de acuerdo, estoy bastante de acuerdo con el comentario,
pero a la vez creo que el ejemplo, lo de Next.js lo entiendo,
pero tampoco lo termino a compartir justamente porque Next.js 13 es el mejor ejemplo
de cómo hacer bien migraciones hacia el futuro.
Y por eso me ha sorprendido.
Me tocó vivir a las malas una migración fallida.
Es que la migración fallida es una mierda, ¿eh?
Como un año escribiendo código y el día del lanzamiento estaba media aplicación rota.
¿Pero sabéis por qué eso falla?
A ver, os voy a explicar otra cosa, que esto es vital en el mundo del desarrollo, ¿vale?
El tema es que si tú quieres hacer una migración de una aplicación, de una web o lo que sea,
tú lo que vas a querer es cuanto antes enviar código a producción con esa migración.
Nunca vas a querer tardar tres meses, seis meses, un año, no tiene sentido.
Tú siempre lo que vas a querer es que cuanto antes le llegue a usuarios reales
y de forma incremental ir creciendo, tú a lo mejor empiezas con una mota de tu nuevo código.
A lo mejor es una mota.
Y a partir de ahí lo que vas haciendo es como si fuese un virus que se fuese expandiendo el nuevo código
y de forma incremental, pero que siempre vaya llegando a usuarios.
Lo que nunca vas a querer es tardar seis meses a llegar a producción.
No tiene sentido.
Porque eso si no, lo que ocurre es lo que dices, ¿no?
Que al final llegas demasiado tarde a producción, no sabes cómo le va a sentar al usuario.
Seguro que os ha pasado alguna vez.
De que de repente entráis a una web, una aplicación, a donde sea,
y tiene un montón de cambios de repente que ya no sabes ni cómo funciona.
Y empieza a haber más cambios porque entonces la empresa se da cuenta que no ha funcionado
e intentan volver hacia atrás, pero probar otras cosas y tal.
Y fatal, fatal.
Y de hecho es una forma no ágil de hacerlo, sinceramente.
Creo que en Platzi recién pasó algo así.
Mira, es verdad.
Y a ver, lo hicieron bien porque escucharon a la gente,
pero sí es verdad que hicieron como un restyling, ¿no?
De toda la plataforma.
Claro, normalmente eso lo mejor es hacerlo de forma incremental.
Porque si no, al final lo que puede ser es que haya un choque con los usuarios.
De que los usuarios no te han dado feedback de forma...
Ha llegado tarde el feedback.
Demasiado tarde.
Que si quieres ser en modo oscuro, que si quieres que sea en modo claro,
un montón de cosas.
Lo mejor es cuanto antes tengas el feedback de usuario y poderlo incorporar al desarrollo.
Y eso es ágil.
Ese es el hacer un desarrollo incremental.
Si tú estás haciendo a oscuras, ¿sabes?
O sea, en una sala escondido durante dos meses, tres meses, seis meses, un rediseño,
y luego llega a producción, vas a tener un montón de errores,
el usuario no va a entender un montón de cosas,
el feedback va a ser un montón, va a ser tarde...
O sea, ese es el problema, ¿no?
Claro, también es importante una buena arquitectura.
Claro, claro.
No, hombre.
Muchas cosas son muy importantes.
Una buena arquitectura, desde luego.
Aparte, sirve mucho para lograr apoyo al negocio, al ver el resultado de inversión.
Muy bien, Facundo.
Totalmente.
Para vender una idea, claro, no es lo mismo venderle a producto, decirle,
oye, no.
Es que necesitamos tener parado el desarrollo del producto tres meses.
¿Vosotros os creéis que alguien va a decir, ah, sí, qué buena idea?
Por muy buena que sea luego la refactorización o lo que sea, no.
O sea, no tiene sentido.
Pero si tú le dices, mira, no vamos a parar el producto,
pero poco a poco, cuando haya un ticket, vamos a aprovechar y esto lo vamos a ir migrando y tal.
Y de forma incremental, seguro que vas a llegar a acuerdos en los que a lo mejor
vas a poder estar refactorizando un día, dos días,
y poco a poco ir sacándolo.
Y tiene mucho más sentido.
Y tiene mucho más sentido.