Tienes Tiempo para Construirlo Dos Veces

Hola a todos. Soy Suez. Soy ingeniero de software, autor, y puedes decir que soy legítimo porque hay una gran pantalla detrás de mí. Así que hoy quiero hablarles sobre las reescrituras de software.

¿Quién ha visto esta cita antes? Si no tienes tiempo para construirlo bien, ¿cuándo tendrás tiempo para construirlo dos veces? No pude encontrar una atribución para esta cita porque muchas personas la han dicho. Lo que quiero decirles hoy es que tendrán tiempo para construirlo dos veces más tarde. Porque más tarde es el momento mágico cuando todo puede suceder. Porque, al menos en una empresa en crecimiento que está yendo realmente bien, más tarde también viene con más dinero, un equipo más grande, más experiencia, una mejor comprensión de tu problema, y simplemente, más tarde es este momento mágico, mágico.

La historia que quiero contarles es cómo reescribimos una aplicación jQuery, sí, una aplicación jQuery en 2020, de jQuery a React, reescritura completa, empezamos desde cero, y mientras lo hacíamos no solo no ralentizamos la velocidad del equipo, en realidad hicimos crecer la empresa cuatro o cinco veces y conseguimos una ronda de Serie B de $100 millones que se anunció en la famosa pantalla de NASDAQ, que por cierto, no sucede solo para las IPOs. Si conoces a las personas correctas, puedes simplemente pagarles cien dólares y apareces allí.

Así que sé, sé, sé, dije jQuery y quién aquí ha usado jQuery en el último, quién recuerda haber usado jQuery. Vale, vale. ¿Quién ha usado jQuery en 2020 justo antes de la pandemia? Vale, tenemos tres manos. Genial. Así que sé que jQuery es malo, pero en realidad sigue siendo súper popular. Esto es lo que tuiteé justo después de que SWIX, Shawn Wang diera una charla en React.com en San Francisco hace un par de meses. Resulta que el 84% de la producción de JavaScript sigue siendo jQuery. Y tiene este bonito gráfico que, vale genial, puedes verlo. Si miras el gráfico, hay como jQuery, 84%, luego tienes jQuery, Migrate, y yo no sé ni qué es eso. Y luego React está en como el 8% de la producción de JavaScript. Sin embargo, eso todavía significa que estás en la conferencia correcta porque React 1, porque ninguno de los otros frameworks están en el gráfico. Así que, al poseer el 8% de la web, React ha ganado las Guerras de Framework, sí, increíble.

La otra objeción que podrías tener a reescribir y empezar desde cero es si alguna vez has leído esta entrada de blog que salió en 2020, no, lo siento, no en 2020, en el año 2000 cuando los blogs todavía eran populares, este tipo de software Jolon que luego pasó a hacer stack overflow y un montón de otras cosas escribió un artículo realmente genial llamado Cosas que nunca deberías hacer y esencialmente explica por qué no todos estamos usando Netscape ahora mismo. ¿Quién recuerda Netscape? Vale. ¿Quién ha usado realmente Netscape? Genial. Vale. Así que hay un par de ustedes. Hace el argumento de que Netscape estaba ganando las guerras de los navegadores hasta que decidieron, sabes qué, Netscape 4 es un poco malo. Vamos a escribir Netscape 5 desde cero. Y luego IE entró y se comió su almuerzo.

Entonces, la historia sobre la reescritura de jQuery a React. Cuando me uní a la empresa en junio de 2020, tenían esta pequeña aplicación. ¿Se reproducirá? Se está reproduciendo. Vale. Entonces, esta es una aplicación jQuery. Se grabó en modo móvil porque eso era todo lo que había. Si abres esto en pantalla completa, todavía se vería tan ancho como se ve ahora. Y esto era aproximadamente 100,000, 200,000 líneas de código jQuery. Nadie sabía exactamente dónde estaban todas las funciones. Si intentabas mover algo, básicamente explotaría en tu cara. Estaba haciendo todas las mejores cosas de jQuery, variables globales, mezclas mágicas que simplemente crean nuevo code. Y gran parte de ello estaba trabajando en el frontend. Y aquí está la parte súper divertida. Cuando entré en la empresa, dije, vale, tenemos que reescribir. Vamos a hacer una SPA basada en React, sin renderizado del lado del servidor, etc. Ahora el renderizado del lado del servidor es popular y todo esto se renderizaba en el servidor porque así es como se usa jQuery. Tomas express, escupes un montón de HTML, luego añades variables globales de jQuery y funciones y funciona, más o menos.

Esto es lo que tenemos ahora. Está un poco mejor diseñado. Creo que se ve mejor. Hay algunos spinners de carga. Estamos usando en realidad React Query, que resolvió muchos de nuestros problemas. Esa fue una de las partes agradables. Y además de verse mejor, también tiene más conversiones, los usuarios están más contentos, nuestros puntajes NPS, eso es el puntaje de promotor neto sobre cuánto disfrutan los usuarios de tu empresa, tu producto en realidad subió. Y el punto que estoy tratando de hacer aquí es que no solo reescribimos la aplicación desde cero, también utilizamos todo lo que aprendimos para mejorar el producto en sí y la reescritura fue lo que nos dio la capacidad de reescribir.

Entonces, y eso es porque escribir software es como patear una lata, sabes, cuando estás caminando, es un bonito domingo, el sol está brillando, y estás caminando por la calle y hay una lata, y obviamente, te acercas y pateas la lata. Y luego sigues caminando y la lata rebota y va al otro lado y tú la pateas desde este lado, y estás como yendo a donde va la lata, ¿verdad? Y eso es más o menos cómo funciona el software también. El software se trata de exploración y descubrimiento lúdico de tu espacio de problemas, algo como patear una lata, sabes, vale, tengo este pequeño problema y voy a resolverlo, pateas la lata un poco más lejos por el camino, luego vas a donde te lleva el software y dices, vale, ahora sé mejor, tengo que intentar patearlo más en esa dirección. Entonces, eso es más o menos de lo que se trataba nuestra reescritura. Estábamos cambiando cosas, actualizando, obteniendo feedback de los usuarios, y esa es la parte importante, porque cuando tienes mal code, el nivel de esfuerzo que se necesita para hacer un cambio aumenta exponencialmente.

Generalmente, construir la primera versión de una aplicación mediocre es súper fácil. Puedes hacerlo de la noche a la mañana, puedes hacer como un primer prototipo muy básico, puedes hacerlo de la noche a la mañana eres como, todos ustedes son personas increíbles. Yo no puedo, soy viejo. Entonces haces la primera versión, y es súper rápida, y la lanzas al mercado. Pero si te tomaras el tiempo para construir una buena versión y trataras de seguir todas las best practices, todos los advice de los libros de texto, te llevaría mucho tiempo construirlo. Sería más difícil empezar.

Entonces esa es la curva del buen code, es muy difícil empezar, pero una vez que lo tienes, es más fácil seguir adelante y hacer mejoras, porque como, especialmente con React, uno de mis cosas favoritas sobre React, comparando el código jQuery con el código React, fue que con jQuery, no quiero tocar nada. Si mueves una función a un archivo diferente, no tienes idea de lo que va a romperse. Con React, puedes simplemente saltar, agarrar una función, y porque todo está autocontenido y solo depende de las props y todo eso, puedes simplemente moverlo a otro lugar y VSCode arregla tus importaciones y todo funciona genial. Así que obtienes mucha de esa flexibilidad que luego, una vez que tienes mucho code y más ingenieros, facilita el trabajo en equipo.

Pero ese espacio en los gráficos, donde el mal code es rápido para empezar y luego se vuelve realmente difícil, y el buen code es lento para empezar y luego se vuelve realmente fácil, eso es lo que yo llamaría tu espacio de oportunidad. Si tú, mierda, ¿cómo iba a explicar esto? Entonces, ese es tu espacio de oportunidad. Ahí es donde puedes obtener mucha retroalimentación muy rápidamente y empezar a usarla en una reescritura que te permite mejorar y obtener un mejor code. Y lo que esperas lograr es que antes de que las dos líneas se crucen, si tu reescritura o si tu refactorización o mejoras no están listas, mueres. Y esa es la parte divertida de trabajar en startups. Es como, o lo hacemos o en realidad no importa porque a nadie le importa una startup cuyo code ya no se usa. Podría usar un ejemplo realmente contundente allí. Pero de todos modos, ¿cómo abordas una reescritura, verdad? Estoy seguro, en realidad, ¿quién aquí ha abogado por dejar de trabajar en características e ir a reescribir el code? Sí. ¿Quién tiene una lista de pendientes de ingeniería a la que nunca llegas? Exactamente. Y la razón por la que eso sucede es porque las personas de negocios no son tan estúpidas como podrías pensar. No tienes tiempo para detener la empresa y simplemente ir a trabajar en la deuda técnica, porque eso es cómo murió Netscape. No fue porque estaban reescribiendo, es porque dijeron, simplemente no vamos a tener una nueva versión del software durante tres años mientras hacemos esto. Y eso no funciona. Lo que sí funciona es algo llamado el patrón Strangler, o puedes, también he oído que se llama la reescritura del Ship of Tethius donde reemplazas lentamente tu code pieza por pieza hasta que no queda nada de tu viejo code. En realidad no recuerdo por qué se llama el patrón Strangler. No es como agarrar el viejo code y estrangularlo hasta que desaparezca. Tiene un origen mucho más agradable. Creo que es algo sobre las enredaderas en la selva. Entonces, hay dos formas en que puedes abordar esto. Siempre que estés construyendo una nueva característica o añadiendo funcionalidad a tu aplicación, puedes decidir si vas a ir de arriba hacia abajo, donde reemplazas páginas enteras con nueva funcionalidad, o puedes ir de abajo hacia arriba, donde creas algo como, en mi empresa, lo llamamos una isla React, donde esencialmente construyes un plug-in tipo GQuery que renderiza React en un div.

Eso realmente funciona muy bien. Si estás reescribiendo una aplicación completa, si tienes tiempo para reescribir toda la aplicación, el enfoque página por página es, creo, mucho más fácil. Lo que hicimos fue que durante aproximadamente un año o seis meses, algo así, tuvimos una experiencia un poco desordenada. Los usuarios utilizarían la aplicación GQuery, harían clic en un botón aleatorio y terminarían en la hermosa aplicación rediseñada React, y luego harían clic en otro botón y volverían a la tierra de GQuery, que parece terrible. Como usuario, es como, ¿qué demonios está pasando aquí? Creo que el mayor ejemplo de esto en la práctica que he visto fue mi banco, donde la página de inicio de sesión era increíble y hermosa, y luego haces clic en iniciar sesión, y estás en esta vieja aplicación desordenada que parece que fue diseñada hace 10 años. Pero siento que, como personas, como usuarios, estamos acostumbrados a estos rediseños, por lo que siempre que los diseñadores hagan un buen trabajo, y mantengan esa continuidad de diseño, o lo que sea que quieras llamarlo, a los usuarios en realidad no les importa. Entienden, sí, sabes, un nuevo BMW sale cada año y tiene parrillas cada vez más grandes, pero sigue siendo un BMW, reconoces que es un BMW, sabes que es un coche, sabes cómo conducirlo, y las cosas principales son las mismas, pero las cosas pequeñas siguen cambiando.

Y el enfoque página por página también te da una excusa o una oportunidad para hacer producto innovación. No solo estás arreglando el code, también estás arreglando cómo funciona el producto. Comienzas con un monopatín, luego construyes un scooter, lo conviertes en una bicicleta, luego tienes una motocicleta, y al final tienes un increíble BMW o Porsche, o simplemente Este coche genial que a todos les va a encantar.

Y la reescritura en realidad, en mi experiencia, a los gerentes de producto les encanta si lo haces de esta manera, porque también odian lidiar con cosas heredadas. Les encantaría simplemente tener nuevas características y vienen a ti con esta gran idea y tú dices, sí, ¿sabes qué? Eso va a ser realmente fácil, podemos construirlo porque estamos desechando todo el viejo code y lo estamos haciendo en el nuevo estilo que es más rápido para trabajar, así que no tenemos que lidiar con todo lo demás, porque déjame decirte, en una compañía más antigua que tuvimos, como, estábamos arrastrando alrededor de cinco años de producto, de iteración de modelo de precios y el PM vino a mí y me dijo, oye, ¿podemos agregar este nuevo tipo de cobro a los usuarios? Y yo dije, sí, podemos cobrarles de otra manera. Va a tomar tres meses agregar eso. Y desafortunadamente decidimos agregar eso y una lección que aprendí es que nunca innoves en la preparación, en tu esquema de precios. La gente solo quiere pagar por mes y no les importa nada más. Simplemente, no vale la pena. Pero sí innova en el producto, sí innova en lo que los usuarios están usando realmente.

Ahora, al final del día, pasamos un año entero reescribiendo la aplicación desde cero. Ahora mismo si vas a nuestra cosa, si haces clic en ciertos botones, todavía vuelves al viejo mundo de jQuery, porque no pudimos actualizar el backend. Y la pregunta podría ser, ¿valió la pena? ¿Valió la pena todo este esfuerzo? ¿Valió la pena poner el esfuerzo para reescribir la aplicación de jQuery a React? Y honestamente, lo fue. Cuando recaudamos la ronda, como la ronda de cien millones de dólares, fue, nuestro esfuerzo fue esencialmente vale medio millón de dólares por empleado, pero la valoración subió a alrededor de tres millones. Puede valer la pena, si tu empresa está en la trayectoria correcta.

Y por favor escucha la última línea de mi tweet allí. Vales mucho dinero para tus empleadores, ve a negociar eso y cobra. Y, de hecho, ahora mismo estoy escribiendo un libro basado en esta experiencia. Va a profundizar mucho más en cómo funcionan los refactors y las reescrituras. Y si quieres ser notificado cuando esté listo, ese es el código QR para ti. Y eso es realmente todo lo que tenía que decir. Buen trabajo, hombre. Gracias. Sí. Oh, hay líneas en el suelo. Entonces, Swissec, charla refrescante. Estaba pensando en una experiencia que tuve cuando estaba entrevistando en una empresa que ahora en el momento en que estaban decidiendo construir su primer prototipo. ¿Vamos a JQuery, lo iniciamos, o vamos a construirlo correctamente? Y para mí, esa fue una decisión difícil, porque no quería ir a ellos si decidían ir al mundo de JQuery bootstrap. Soy un poco snob, quizás. ¿Pero qué te hizo decidir que realmente querías hacerlo? Entonces, esa es realmente una historia divertida, porque cuando el jefe de ingeniería me convenció para venir a reescribir su aplicación JQuery a React, dijo, necesitamos hacer esto porque es imposible contratar ingenieros para que trabajen en JQuery.

Nadie quiere hacer esto. Y sí, por eso fui. Porque era como, sí, tengo la oportunidad de design toda la experiencia con React, el framework, establecer el futuro de la empresa, y creo que hasta ahora ha funcionado bien.

Entonces, ¿te uniste cuando la parte de React jQuery ya estaba hecha en producción? Vale. Sí. Así que me uní cuando eso ya estaba listo. Era lo mejor que sabían en ese momento. Era lo mejor, era la forma más rápida para ellos de construirlo. Sí. Y luego dijeron, necesitamos un experto en React para que venga y lo arregle para nosotros. Y tú eres el chico para hacerlo. Genial. Bueno, buena experiencia.

Así que vamos a pasar a las preguntas de la audiencia. Pregunta de anónimo. ¿La aplicación sigue siendo mobile first? Creo que lo mostraste, ¿verdad? Sí. ¿Verdad? Así que estamos usando un framework de CSS en componentes. Como dije, un framework de CSS y JS llamado Team UI. Eso es súper adaptable. Así que la aplicación es mobile first, pero funciona en todas partes y se adapta automáticamente. Y esa fue una de las razones por las que reescribimos, porque podríamos hacerlo más fácil con las herramientas modernas. Pero, ¿todavía ves en tus estadísticas que tal vez nueve de cada diez personas todavía acceden a través del móvil porque están acostumbrados a acceder al producto desde el móvil? Y en realidad eso fue disminuyendo lentamente. A medida que la aplicación empezó a funcionar mejor en los navegadores, la gente empezó a acceder más desde los portátiles. Y probablemente también nuevos usuarios que no sabían que no había experiencia de escritorio. Sí. Genial. ¿Cómo te proteges del alcance excesivo cuando se trata de la innovation del producto durante la reescritura? Correcto. El alcance excesivo es principalmente... Honestamente, la mejor solución que encontré para el alcance excesivo es unirme a una empresa que está creciendo realmente rápido y tiene usuarios golpeando la puerta.

Sí. Porque entonces todos están de acuerdo con, está bien, vamos a sacar esto rápidamente. No tenemos tiempo para hacerlo perfecto porque literalmente estamos perdiendo usuarios al no poder enviar. Eso hace que sea realmente fácil decirle a tus PMs, oye, no tenemos tiempo para esto. Sí, tenemos que seguir adelante.

¿Y en la aplicación Legacy, había alguna prueba escrita o simplemente tenías que esperar que lo que reescribiste fuera lo mismo? Había algunas pruebas en la antigua aplicación. El beneficio de nuestra reescritura fue que los PMs también querían mejorar el producto. Así que todas las pruebas antiguas simplemente ya no se aplicaban porque las características eran diferentes. No era solo una reescritura desde una perspectiva técnica, también era una reinvención y mejora de la aplicación.

Sí, está bien, no fue una reescritura uno a uno. Sí, no fue una reescritura uno a uno. Entonces es como, ya sabes, estás convirtiendo un submarino en un barco, no muchas pruebas todavía se aplican. Sí, tal vez una o dos pruebas, se hace esta llamada backend, pero eso es todo. Sí, exactamente.

Está bien. ¿Y luego, había alguna funcionalidad del lado del servidor? ¿Y si sí, qué framework o biblioteca utilizaste? Había mucha funcionalidad del lado del servidor, porque esta era una aplicación Express que estaba renderizando HTML y luego jQuery se hacía cargo. Así que tenían como, básicamente tenían hidratación antes de que supiéramos sobre la hidratación. Así que todo el backend se quedó. Lo convertimos en llamadas API y ahora estamos reescribiendo lentamente el backend también. Está escrito en Express, Node.js con JavaScript puro.

Bueno, parece una sólida ingeniería de software. Sí, el backend, hicieron un gran trabajo. Bien, entonces, eso es todo el tiempo que tenemos para SwissEx, así que voy a agradecerte. Bueno tenerte. ¡Así que, un gran aplauso por supuesto!