La Trampa de la Reescritura

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Vamos a desechar todo y empezar de nuevo. Suena genial, ¿verdad? Aunque esto puede sentirse muy bien, rara vez acelera algo. Te mostraré por qué una reescritura completa generalmente no es lo que quieres.

This talk has been presented at TechLead Conference 2023, check out the latest edition of this Tech Conference.

FAQ

La trampa de la reescritura es el impulso inicial de desechar un sistema existente y comenzar desde cero, lo cual puede parecer productivo al principio pero a menudo lleva a problemas a largo plazo como la acumulación de deuda técnica y la repetición de errores pasados.

Las principales razones incluyen la preferencia personal por ciertas tecnologías o arquitecturas, el deseo de no aprender sistemas o tecnologías existentes, y el ego, que permite establecer reglas propias y trabajar de manera más cómoda.

Phil sugiere esperar 100 días para poder aprender sobre el sistema actual y evaluar si las decisiones pasadas son realmente inadecuadas, o simplemente diferentes a las preferencias personales, evitando decisiones precipitadas.

Comenzar desde cero puede llevar a una falsa sensación de progreso rápido al principio, pero a menudo omite problemas y casos límite existentes, lo que puede resultar en un aumento de la deuda técnica y una desaceleración del progreso a largo plazo.

Phil aconseja aprender y comprender las decisiones pasadas y las tecnologías usadas antes de realizar cambios, hablando con las personas involucradas y retrasando los juicios para evitar repetir errores y mejorar efectivamente el sistema.

Phil argumenta que la mejora gradual permite entender y resolver problemas del sistema existente, reduciendo su complejidad y obteniendo beneficios a largo plazo, mientras que la reescritura completa puede parecer más rápida inicialmente pero conduce a problemas futuros.

Philipp Giese
Philipp Giese
22 min
09 Mar, 2023

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla discute la 'trampa de la reescritura' en el desarrollo de software, donde el impulso de comenzar desde cero a menudo conduce a resultados pobres. Se enfatiza la importancia de comprender el proyecto existente antes de tomar grandes decisiones técnicas y los beneficios de la mejora gradual. La charla también destaca los desafíos y peligros de una reescritura completa, como la falsa sensación de productividad, problemas con casos extremos y la acumulación de deuda técnica. Se enfatiza la necesidad de comprender el sistema y sus influencias, atender las necesidades de las partes interesadas fuera de la ingeniería y enfocarse en crear valor.
Available in English: The Rewrite Trap

1. The Rewrite Trap

Short description:

Hola a todos. Mi nombre es Phil. Soy ingeniero de software en Brighter. Hoy me gustaría hablarles sobre lo que llamo la trampa de la reescritura. El impulso de comenzar desde cero a menudo surge de no querer aprender nuevos conceptos, no alinearse con la arquitectura existente y el deseo de trabajar de una manera que se ajuste a las preferencias personales. Sin embargo, estas razones rara vez tienen éxito a largo plazo. Es importante tomar el tiempo para comprender el proyecto existente antes de tomar cualquier decisión técnica importante. La trampa radica en la creencia de que una reescritura completa conducirá a mejores resultados, cuando en realidad, la mejora gradual suele ser un enfoque más efectivo.

Hola a todos. Mi nombre es Phil. Soy ingeniero de software en Brighter. He sido líder técnico antes y también CTO, aunque me despidieron de ese trabajo, más sobre eso más adelante.

Y hoy me gustaría hablarles sobre lo que llamo la trampa de la reescritura. Y primero, antes de comenzar, permítanme establecer el escenario. ¿De qué tipo de reescritura estamos hablando? Definitivamente no es aquella en la que conoces el proyecto durante meses o años. Estás muy familiarizado con todos los detalles, la tecnología, las decisiones arquitectónicas, todo eso, y estás absolutamente seguro de lo que necesitas hacer para poner esto en marcha, ¿verdad? Incluso puede haber un nuevo proyecto, ¿verdad? Y tomas la decisión de no quedarte con la pila actual o la plataforma heredada, sino comenzar desde cero, ¿verdad? Esto no es de lo que trata esta charla, ¿verdad? Porque creo que la reescritura o comenzar desde cero podría ser la mejor opción. Estoy hablando de situaciones en las que podrías ser el nuevo líder técnico en la ciudad o el nuevo CTO en la ciudad. Te unes a una empresa que tiene un producto existente. Hay una pila, hay software allí. Y tienes esa sensación de que después de mirarlo durante uno o dos días, sería mejor tirar todo y comenzar de nuevo, ¿verdad? De eso trata esta charla, ¿verdad?

Entonces, comencemos con ¿de dónde viene ese impulso? Y creo que hay tres razones principales. La primera es que no necesitas aprender nuevos conceptos, ¿verdad? Por ejemplo, digamos que es una aplicación de cliente, está escrita en React, pero a ti te gusta más Vue o Svelte o cualquier otra cosa, ¿verdad? Y al adentrarte en React, inmediatamente tienes esa sensación repulsiva de que realmente no quieres meterte en esto, ¿verdad? Entonces, si lo descartas y lo reescribes en tu pila preferida, ese problema desaparecería. Lo mismo ocurre con los lenguajes de programación, metodologías, lo que sea, ¿verdad? Todo lo que no estás acostumbrado a, inmediatamente dices tal vez no lo hagamos. La segunda cosa también es que alguien más construyó eso, ¿verdad? Entonces, si realmente te gusta cierta arquitectura, digamos por ejemplo que realmente te gusta la programación funcional, pero el producto actual está construido de una manera muy orientada a objetos, entonces, ja, ya sabes, esos dos mundos podrían no alinearse tan bien, ¿verdad? Y siempre se sentiría como un obstáculo familiarizarse con todo, ¿verdad? Y quizás ya te hayas dado cuenta de que hay un patrón aquí. Y el patrón no es necesariamente que las elecciones tecnológicas, las elecciones de lenguajes de programación, las elecciones de arquitectura sean mejores o peores. Es simplemente que son diferentes y que, intrínsecamente, si algo es diferente a lo que preferimos, tenemos que luchar contra ese impulso de simplemente desecharlo y convertirlo en algo que nos guste. Un colega mío una vez me dio el consejo de esperar 100 días antes de tomar decisiones técnicas importantes una vez que te unes a un nuevo trabajo, ¿verdad? Porque en 100 días puedes aprender mucho y también puedes descubrir si algo, una elección del pasado, es realmente peor de lo que querías usar. ¿Es un problema que sea orientado a objetos? ¿Debería ser funcional? O si esto fue simplemente tu reacción inicial a algo en particular y simplemente no te gustó antes, ¿verdad? Pero probablemente después de 100 días, también te acostumbraste y tal vez ya no sea tan malo. Personalmente, debo admitir que siempre acorté ese período a 50 días. Porque especialmente cuando era CTO, no pude convencer a mi CEO de esperar, ya sabes, casi un tercio de año antes de comenzar a tomar decisiones importantes. Simplemente comienza la vida y tienes que hacer lo que tiene sentido en ese momento. Ahora pasemos a la tercera parte. Y esa es la parte más egómana, ¿verdad? Si simplemente desechas todo, puedes trabajar de la manera que quieras, ¿verdad? Tú estableces todas las reglas. Esto definitivamente se siente cómodo, ¿verdad? La gran pregunta aquí es simplemente, ¿eso, ya sabes, tiene sentido a largo plazo, ¿verdad? ¿Tu forma de trabajar, por ejemplo, es compatible con la forma en que funciona la empresa, ¿verdad? Y sí, todas estas cosas que acabo de describir, inicialmente, podrían parecer buenas razones para comenzar desde cero, ¿verdad? Y definitivamente podemos convencernos de los beneficios de cualquiera de estas opciones. Pero la pregunta es, ¿realmente valen la pena? Y creo que rara vez lo hacen. Y aquí es donde entra la trampa porque inicialmente, si observamos estos proyectos, he dibujado dos líneas ficticias, esencialmente, la línea verde representa un proyecto de software existente y no lo reescribes, sino que intentas mejorarlo gradualmente, avanzar en el proyecto y mejorarlo. Y la línea morada representa la reescritura completa y las X son simplemente el tiempo en el eje X y el eje Y es el resultado.

2. The Rewrite Trap: Falsa Sensación de Productividad

Short description:

Si comienzas una reescritura, no hay nada allí, nada que te detenga. Puedes sacar muchas cosas al principio muy rápido. Las personas que se quedan con el código existente e intentan mejorarlo gradualmente primero tienen que lidiar con los detalles, aprender las elecciones arquitectónicas y mejorar gradualmente el sistema en funcionamiento. Esa falsa sensación de productividad al principio lleva a las personas a tomar esas decisiones de reescritura.

¿Cuánto puedes lograr realmente? Y obviamente, si comienzas una reescritura, no hay nada allí, nada que te detenga. Puedes sacar muchas cosas al principio muy rápido. Incluso podrías engañarte pensando, wow, esta debe haber sido la mejor opción. Estamos tan rápidos. Todo se mueve rápido. Eso es genial, ¿verdad? Bueno, ya sabes, las personas que se quedan con el código existente e intentan mejorar gradualmente primero, tienen que lidiar con los detalles, aprender las elecciones arquitectónicas, ya sabes, ver qué hay y mejorar gradualmente el sistema en funcionamiento, básicamente. Y aquí es donde entra la trampa, realmente, ya sabes, esa falsa sensación de productividad al principio, es lo que creo que lleva a las personas a tomar esas decisiones de reescritura. Y te doy una pista, tal vez también sea bueno para tu carrera hacer esto, ¿verdad? Porque, no sé cuánto tiempo, ya sabes, las fases uno, dos y tres duran. Pero si te vas en la fase uno, o al final de la fase uno, todo lo que has hecho hasta ahora parece muy productivo. Has hecho un gran trabajo. Entonces podrías ser, ya sabes, el líder técnico realmente bueno que logra hacer las cosas y que hace las cosas que nadie más quería hacer. Y eso te ayuda a progresar, ya sabes, tal vez hazlo si es bueno para ti, pero yo no soy esa persona.

3. Phase One: Fast Start and Initial Progress

Short description:

Comencemos con la fase uno de la reescritura. En esta fase, desarrollas rápidamente las primeras características y funcionalidades básicas. Si bien el progreso inicial puede parecer lento para aquellos que trabajan con el código existente, es importante comprender las complejidades del sistema y los casos límite. La reescritura se siente productiva, pero el progreso puede no ser visible de inmediato.

Pero, ya sabes, veamos todos estos detalles y comencemos con la fase uno. Ya he dicho que la reescritura será, ya sabes, rápida desde el principio. Implementarás rápidamente las primeras características. Harás lo básico, no sé, ya sabes, tener un flujo de registro, tener las primeras características importantes en marcha. Todo es rudimentario porque trabajas de forma iterativa y, ya sabes, haces todo lo necesario y siempre tienes algo que presentar a la gente. Mientras tanto, las personas que se quedan con el código existente probablemente tienen poco que presentar porque necesitan comprender todo lo que está allí. Necesitan averiguar, vale, ¿qué pertenece junto? ¿Cómo funcionan realmente las cosas? ¿Dónde están los casos límite y todas estas cosas? Entonces, en la fase uno, la reescritura se siente bien y avanzas, mejorando lo que ya está allí, pero no se siente tan bien porque parece que no estás progresando en absoluto.

4. Fase Dos: Problemas y Deuda Técnica

Short description:

La fase dos de la reescritura pasa por alto los problemas y casos límite del sistema antiguo. Las suposiciones hechas durante la reescritura no encajan bien con estos casos, lo que lleva a retrabajos y a la acumulación de deuda técnica. El progreso se ralentiza, los resultados sufren y el sistema se convierte en un desastre.

Estas cosas comienzan a verse diferentes cuando entras en la fase dos porque lo que la reescritura pasó por alto por completo fueron, ya sabes, los problemas y los casos límite que la gente había encontrado antes. Esa gran base de código heredada probablemente no era tan complicada, solo, ya sabes, por pura coincidencia, pero probablemente por una razón. Así que nuestra gran reescritura en algún momento se encontrará con esa parte donde entran los casos límite, donde entran las peculiaridades y te darás cuenta de que, dado que no aprendiste todas estas cosas de antemano y ni siquiera te molestaste en entender por qué el antiguo sistema se convirtió en lo que era. Hiciste muchas suposiciones, construyendo tu nuevo software que simplemente no encajan bien con, ya sabes, esos casos límite y otros requisitos que tienes. Así que tienes que comenzar a retrabajar cosas. Tienes que encontrar la manera de incorporar otras cosas. Pero ya sabes, como has sido tan productivo antes, ¿verdad? La gente tiene la suposición de que, ya sabes, las cosas se moverán rápido y quieren que se muevan rápido y eventualmente terminarás agregando deuda técnica nuevamente, ¿verdad? Tienes que, ya sabes, tomar atajos, tratar de mantener ese impulso en movimiento, pero eventualmente lo que sucederá es que tu progreso se ralentizará, los resultados disminuirán y sí, simplemente tienes que navegar hacia el mismo desastre que el antiguo

5. The Rewrite Trap: Understanding and Improving

Short description:

En la fase dos, los esfuerzos iniciales de comprensión y mejora gradual del sistema existente comienzan a dar sus frutos. La gran reescritura en la fase tres se convierte en el nuevo sistema heredado, lo que lleva a una interrupción en la entrega futura debido a la acumulación de deuda técnica. Mantener el sistema existente y realizar mejoras graduales permite comprender mejor el software y la capacidad de realizar cambios importantes. Es importante posponer el juicio al unirse a un nuevo proyecto y aprender por qué las cosas son como son. Acepta las partes que no comprendes y ten discusiones para obtener información.

era antes. Mientras que las personas que, ya sabes, se tomaron el tiempo para comprender realmente lo que hay y descubrir cómo mejorarlo gradualmente. En la fase dos, estos esfuerzos iniciales comenzarán a dar sus frutos porque al reducir la complejidad con el tiempo, realmente, ya sabes, haciendo las refactorizaciones necesarias de una manera que, ya sabes, se ajuste al sistema, realmente pueden comenzar a desenredar las cosas, tal vez, ya sabes, separar los monolitos en módulos claros con buena cohesión, ya sabes, no como desacoplar el sistema donde todo está acoplado a todo. Y realmente comenzarán a obtener impulso ahora, ¿verdad? Entonces será más rápido agregar cosas nuevas, cambiar cosas porque las personas que trabajan en el proyecto o producto ahora conocerán mejor lo que hay y cómo funcionan las cosas. Correcto. Y esto nos lleva a la fase tres. En la fase tres, básicamente la gran reescritura es ahora el nuevo sistema heredado, ¿verdad? Porque no te molestaste en, ya sabes, entender las cosas y porque intentaste mantener tu impulso y te has navegado también en una situación en la que el mundo exterior esperaba características rápidas de ti, has acumulado tanta deuda técnica que ahora la entrega futura se detiene en seco. Y, um, quiero decir, si tienes suerte, has dejado el proyecto antes, uh, si no tienes suerte, entonces probablemente este también sea el momento en que otro líder técnico te reemplace, ¿verdad? Y lo más probable es que la historia se repita con otra reescritura. Correcto. Pero las personas nuevamente, que, ya sabes, se quedaron con lo que había y lo mejoraron gradualmente, ahora podrían cosechar los grandes beneficios, ¿verdad? Es posible que no estén en un estado en el que el software sea simplemente, es bastante bueno. Comprenden como una super buena comprensión de lo que está sucediendo y pueden simplemente, ya sabes, realizar cambios en las partes, um, que son realmente importantes. Y eso, uh, y también construí, ahora construye una arquitectura que respalde esos cambios y respalde también el software, ya sabes, para el propósito que se pretendía hacer. Um, y sí, esto es básicamente la trampa aquí, ¿verdad? Que la euforia inicial en torno a la reescritura lleva a su desaparición y luego a la siguiente, um, reescritura. Y una vez más, algunos, um, consejos carrera, ya sabes, intenta irte al final de la etapa uno, porque entonces eres la persona genial que acaba de hacer las cosas. Um, y todo lo que sucede después, uh, se atribuye en su mayoría, ya sabes, a que ya no estás allí. Creo, oh, ahora mi nombre todavía. Entonces, uh, en el momento en que se fue, todo se desmoronó. Correcto. Pero sabes que ahora no fue realmente el caso. Correcto. Pero, um, puedes usar eso si estás, ya sabes, no digo que debas usarlo, pero podrías. Entonces veamos qué debemos hacer en su lugar, ¿verdad? Y ya he esbozado esto antes, uh, y, uh, nuevamente, ya sabes, tres cosas clave. En primer lugar, si te unes a un nuevo proyecto, intenta posponer el juicio tanto como sea posible, ¿verdad? Siempre supón que las personas que trabajaron en el producto antes trabajaron con las mejores intenciones y simplemente, ya sabes, tomaron las mejores decisiones que pudieron en cualquier momento dado. Correcto. Um, todos sabemos que, ya sabes, uh, ya sabes, la mejor elección con el mejor conocimiento en, ya sabes, hace cinco meses probablemente no es la mejor elección ahora. Um, pero esto establece el escenario para un clima donde quieres aprender, donde quieres comprender por qué ciertas cosas son como son. Uh, y necesitas hacer esto para realmente mejorarlas, ¿verdad? Porque si descartas algo solo porque no te gusta, bueno, probablemente seas propenso a cometer los mismos errores nuevamente, ¿verdad? Entonces, aprender, hablar con las personas y comprender por qué las cosas son de cierta manera es, uh, el primer punto clave aquí. La segunda cosa es que necesitas comprender, o como hay, habrá piezas que no comprendas, ¿verdad? Y está bien, ¿verdad? Algunas cosas pueden parecer muy extrañas y no puedes encontrar ninguna buena explicación de por qué sería así. Y aquí es donde necesitas entrar y realmente tener discusiones con las personas y decir, ya sabes, no entiendo, ya sabes, también sé claro acerca de lo que no entiendes, lo que, ya sabes, lo que piensas cómo debería ser. Y que te gustaría aprender, ya sabes, por qué no es de cierta manera, no, en algunas situaciones o en muchas situaciones, probablemente las personas te dirán que simplemente no tuvieron tiempo para hacerlo.

6. Understanding the System and Its Influences

Short description:

El sistema alrededor de los desarrolladores a menudo no brinda el apoyo que necesitan para construir lo correcto. Como líder, es tu responsabilidad crear un sistema donde puedan hacer su mejor trabajo. Comprender la dinámica de la empresa y hablar con personas fuera de la ingeniería es crucial. Las ventas, el marketing y otros factores influyen en el sistema. Es importante atender sus necesidades y no enfocarse solo en mejoras técnicas. Ignorar el sistema existente y centrarse únicamente en las mejoras técnicas puede llevar al fracaso y ser reemplazado por alguien que haga una reescritura completa.

Probablemente sabemos que deberíamos haberlo hecho así, pero bueno, ya sabes, el plazo se acercaba. Pero estas discusiones te ayudan a llevarte bien con las personas y también a comprender que las personas realmente, realmente tienen el deseo de construir lo correcto, pero ya sabes, el sistema que los rodea simplemente no les dio el apoyo que necesitaban para hacerlo realmente. Y, ya sabes, como líder, líder técnico, CTO, lo que sea, esto es ahora tu responsabilidad, esencialmente, ahora debes asegurarte de crear un sistema para ellos, donde puedan hacer el trabajo adecuado. Correcto. Y a veces también, ya sabes, también debes hablar con personas fuera del área de desarrollo, ¿verdad? Hablar con ventas, hablar con marketing porque, ya sabes, es probable que también hayan influido en tu architecture actual y necesitas comprender por qué ciertas cosas eran importantes, ¿verdad? Si estás en una startup, ya sabes, el dinero necesita entrar, ¿verdad? Así que a veces tienes que, ya sabes, sacar esa cosa que simplemente va a firmar el próximo acuerdo, porque de lo contrario la empresa ya no existiría. Estas son todas buenas razones para hacer, um, algunos atajos en la tecnología. Realmente no quería creer eso al principio de mi career. Ahora creo que entiendo mejor a algunos vendedores. Y esto también es lo tercero que debemos conocer del sistema, ¿verdad? Eres un grupo de personas y el departamento de ingeniería o I+D dentro de una empresa no es su propio universo. Hay factores a su alrededor que influyen en el sistema. El CEO, ventas, marketing, ya sabes, todos ellos esencialmente combinados. Y necesitas comprender cómo funciona la empresa para poder navegar en ella de una manera que puedas lograr, ya sabes, el éxito. Y, uh, esto no es una tarea fácil. Esto también requiere hablar mucho también con personas fuera de, um, uh, fuera de la ingeniería y también comprender sus necesidades. Como, ya sabes, ¿qué necesitan las personas? Y te daré el ejemplo, por ejemplo, ya sabes, cuando me uní como CTO, um, ya sabes, no podía creer lo que estaba viendo, ¿verdad? No había pruebas, no había una definición de lo que se suponía que debía hacer el producto. Um, no teníamos ningún informe de errores. Y el CEO siempre me pedía un plan para cuando se terminaran las características. Como, ya sabes, no puedo, no sé, ni siquiera sé qué hay. Así que no puedo decirte nada sobre cuándo se terminará lo próximo. Intenté explicar mucho y, en última instancia, no funcionó. Pero esto también se debe a que no reconocí completamente el sistema allí, ¿verdad? Porque el sistema con el CEO existente, el cliente existente, el director de clientes principales llevó a esto, ¿verdad? Y, ya sabes, no me molesté en comprender exactamente cuáles son sus necesidades y tratar de satisfacerlas siempre. Entré allí y simplemente con una especie de enfoque técnico completo, ¿quieres todo eso, verdad? Decir, está bien, sé que todo esto es malo. Necesitamos hacer esto, ¿verdad? Necesitamos agregar monitoreo. Necesitamos agregar algunas pruebas. Necesitamos agregar, ya sabes, algo de automation en torno a las versiones. Y luego podemos trabajar en el camino a través de las dificultades. Y, en última instancia, tampoco reescribí activamente, sino que mejoré lo que había. Y con eso, en última instancia, fallé en su opinión porque fue muy lento y, en última instancia, ya sabes, fui despedido cuando la curva comenzó a inclinarse cuando, ya sabes, no teníamos más errores de los que podíamos solucionar o cuando comenzamos a entregar características en un cronograma predecible o más predecible, um, donde, curiosamente, alguien más vino y el CEO contrató a alguien que hizo una reescritura completa y fueron súper rápidos. Y, en última instancia, recibí la noticia, dijeron, ya sabes, míralos, en un mes construyeron eso.

7. The Importance of Understanding and Creating Value

Short description:

Conoce el sistema y las necesidades de las personas para atender sus respectivas necesidades. Enfócate en lo que importa y crea valor. Sal de tu zona de confort y comprende las necesidades de las personas que te son ajenas. Aprender es una parte crucial del trabajo. Reconstruye las partes que realmente importan y crean valor para tus clientes. No hay una regla estándar para encontrar estas partes, pero confía en ti mismo para hacerlo.

Y en tres cuartos de año, no lograste eso. Así que estás fuera, ya sabes, una decisión comprensible ahora. Um, um, pero aún así, ¿verdad?, esto es lo que quiero decir. Conoce el sistema, conoce las necesidades de las personas para que también puedas atender las respectivas necesidades que las personas tienen y darles una historia adecuada, ¿verdad? Sabes cómo, o sabes cómo creo que deberías trabajar, pero aún así necesitas crear una historia para todas las demás personas, um, que también se sientan cómodas con ese enfoque.

Entonces, en esencia, la conclusión es hacer lo que importa, ¿verdad? Um, no intentes estar ocupado, um, pero sabes, enfócate en las cosas que realmente, ya sabes, crean valor, ¿verdad? Tienes que salir de tu zona de confort. Y especialmente con eso, quiero decir, tienes que hablar con mucha gente y, uh, tienes que tratar de entender también las necesidades de las personas que te son tan ajenas. Para mí personalmente, siempre fue ventas, como, esto es un mundo completamente diferente. Um, necesitas reconocer que simplemente no tienes todas las respuestas. No lo sabes todo. Y está bien. Aprender es, ya sabes, como probablemente sabes, la parte más importante del trabajo, uh, y necesitas, ya sabes, vas a tener que aprender mucho más.

De acuerdo. Y al final, una vez que hayas descubierto todo eso, necesitas reconstruir las partes que realmente importan. Y esto es una charla en sí misma. Y sabes, tienes suerte porque ya di esa charla. Se llama, uh, abrazar el legado. Si quieres verla, la encontrarás en mi blog, uh, philbeazit.com, um, de acuerdo. Segmento de patrocinio terminado, pero en serio, ¿verdad? Muchas de las cosas que quieres rehacer al principio simplemente no son importantes. ¿Verdad? Um, las partes que realmente importan son todas las partes que crean valor para tus clientes y también crear valor para nuestros clientes podría significar que esencialmente te haga más rápido y te permita entregar software de alta calidad más rápido. ¿Verdad? Y, um, no hay una regla estándar para encontrarlas, pero supongo que lo harás. Confío en ti. Y con eso, te despido. Esto fue la trampa de la reescritura. Mi nombre es Phil Giese. Nos vemos por ahí.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Depuración de JS
React Summit 2023React Summit 2023
24 min
Depuración de JS
Top Content
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.
Un Marco para Gestionar la Deuda Técnica
TechLead Conference 2023TechLead Conference 2023
35 min
Un Marco para Gestionar la Deuda Técnica
Top ContentPremium
Today's Talk discusses the importance of managing technical debt through refactoring practices, prioritization, and planning. Successful refactoring requires establishing guidelines, maintaining an inventory, and implementing a process. Celebrating success and ensuring resilience are key to building a strong refactoring culture. Visibility, support, and transparent communication are crucial for addressing technical debt effectively. The team's responsibilities, operating style, and availability should be transparent to product managers.
Construyendo un Asistente AI Activado por Voz con Javascript
JSNation 2023JSNation 2023
21 min
Construyendo un Asistente AI Activado por Voz con Javascript
Top Content
This Talk discusses building a voice-activated AI assistant using web APIs and JavaScript. It covers using the Web Speech API for speech recognition and the speech synthesis API for text to speech. The speaker demonstrates how to communicate with the Open AI API and handle the response. The Talk also explores enabling speech recognition and addressing the user. The speaker concludes by mentioning the possibility of creating a product out of the project and using Tauri for native desktop-like experiences.
Una Guía Práctica para Migrar a Componentes de Servidor
React Advanced 2023React Advanced 2023
28 min
Una Guía Práctica para Migrar a Componentes de Servidor
Top Content
React query version five is live and we'll be discussing the migration process to server components using Next.js and React Query. The process involves planning, preparing, and setting up server components, migrating pages, adding layouts, and moving components to the server. We'll also explore the benefits of server components such as reducing JavaScript shipping, enabling powerful caching, and leveraging the features of the app router. Additionally, we'll cover topics like handling authentication, rendering in server components, and the impact on server load and costs.
Solucionando Problemas de Rendimiento en React
React Advanced 2023React Advanced 2023
22 min
Solucionando Problemas de Rendimiento en React
Top Content
This Talk discusses various strategies to improve React performance, including lazy loading iframes, analyzing and optimizing bundles, fixing barrel exports and tree shaking, removing dead code, and caching expensive computations. The speaker shares their experience in identifying and addressing performance issues in a real-world application. They also highlight the importance of regularly auditing webpack and bundle analyzers, using tools like Knip to find unused code, and contributing improvements to open source libraries.
De Monolito a Micro-Frontends
React Advanced 2022React Advanced 2022
22 min
De Monolito a Micro-Frontends
Top Content
Microfrontends are considered as a solution to the problems of exponential growth, code duplication, and unclear ownership in older applications. Transitioning from a monolith to microfrontends involves decoupling the system and exploring options like a modular monolith. Microfrontends enable independent deployments and runtime composition, but there is a discussion about the alternative of keeping an integrated application composed at runtime. Choosing a composition model and a router are crucial decisions in the technical plan. The Strangler pattern and the reverse Strangler pattern are used to gradually replace parts of the monolith with the new application.

Workshops on related topic

Construyendo una Aplicación de Shopify con React & Node
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Construyendo una Aplicación de Shopify con React & Node
Top Content
Workshop
Jennifer Gray
Hanna Chen
2 authors
Los comerciantes de Shopify tienen un conjunto diverso de necesidades, y los desarrolladores tienen una oportunidad única para satisfacer esas necesidades construyendo aplicaciones. Construir una aplicación puede ser un trabajo duro, pero Shopify ha creado un conjunto de herramientas y recursos para ayudarte a construir una experiencia de aplicación sin problemas lo más rápido posible. Obtén experiencia práctica construyendo una aplicación integrada de Shopify utilizando el CLI de la aplicación Shopify, Polaris y Shopify App Bridge.Te mostraremos cómo crear una aplicación que acceda a la información de una tienda de desarrollo y pueda ejecutarse en tu entorno local.
Construye una sala de chat con Appwrite y React
JSNation 2022JSNation 2022
41 min
Construye una sala de chat con Appwrite y React
Workshop
Wess Cope
Wess Cope
Las API/Backends son difíciles y necesitamos websockets. Utilizarás VS Code como tu editor, Parcel.js, Chakra-ui, React, React Icons y Appwrite. Al final de este masterclass, tendrás los conocimientos para construir una aplicación en tiempo real utilizando Appwrite y sin necesidad de desarrollar una API. ¡Sigue los pasos y tendrás una increíble aplicación de chat para presumir!
Problemas difíciles de GraphQL en Shopify
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Problemas difíciles de GraphQL en Shopify
Workshop
Rebecca Friedman
Jonathan Baker
Alex Ackerman
Théo Ben Hassen
 Greg MacWilliam
5 authors
En Shopify a gran escala, resolvemos algunos problemas bastante difíciles. En este masterclass, cinco oradores diferentes describirán algunos de los desafíos que hemos enfrentado y cómo los hemos superado.

Tabla de contenidos:
1 - El infame problema "N+1": Jonathan Baker - Vamos a hablar sobre qué es, por qué es un problema y cómo Shopify lo maneja a gran escala en varios APIs de GraphQL.
2 - Contextualizando APIs de GraphQL: Alex Ackerman - Cómo y por qué decidimos usar directivas. Compartiré qué son las directivas, qué directivas están disponibles de forma predeterminada y cómo crear directivas personalizadas.
3 - Consultas de GraphQL más rápidas para clientes móviles: Theo Ben Hassen - A medida que tu aplicación móvil crece, también lo harán tus consultas de GraphQL. En esta charla, repasaré diversas estrategias para hacer que tus consultas sean más rápidas y efectivas.
4 - Construyendo el producto del futuro hoy: Greg MacWilliam - Cómo Shopify adopta las características futuras en el código actual.
5 - Gestión efectiva de APIs grandes: Rebecca Friedman - Tenemos miles de desarrolladores en Shopify. Veamos cómo estamos asegurando la calidad y consistencia de nuestras APIs de GraphQL con tantos colaboradores.
Construye Aplicaciones Modernas Utilizando GraphQL y Javascript
Node Congress 2024Node Congress 2024
152 min
Construye Aplicaciones Modernas Utilizando GraphQL y Javascript
Workshop
Emanuel Scirlet
Miguel Henriques
2 authors
Ven y aprende cómo puedes potenciar tus aplicaciones modernas y seguras utilizando GraphQL y Javascript. En este masterclass construiremos una API de GraphQL y demostraremos los beneficios del lenguaje de consulta para APIs y los casos de uso para los que es adecuado. Se requiere conocimiento básico de Javascript.
De 0 a Autenticación en una Hora para tu Aplicación JavaScript
JSNation 2023JSNation 2023
57 min
De 0 a Autenticación en una Hora para tu Aplicación JavaScript
WorkshopFree
Asaf Shen
Asaf Shen
La autenticación sin contraseña puede parecer compleja, pero es fácil de agregar a cualquier aplicación utilizando la herramienta adecuada.
Mejoraremos una aplicación JS de pila completa (backend Node.js + frontend Vanilla JS) para autenticar usuarios con contraseñas de un solo uso (correo electrónico) y OAuth, incluyendo:
- Autenticación de usuario: Gestión de interacciones de usuario, devolución de JWT de sesión / actualización- Gestión y validación de sesiones: Almacenamiento seguro de la sesión para solicitudes posteriores del cliente, validación / actualización de sesiones
Al final del masterclass, también abordaremos otro enfoque para la autenticación de código utilizando Flujos de Descope en el frontend (flujos de arrastrar y soltar), manteniendo solo la validación de sesión en el backend. Con esto, también mostraremos lo fácil que es habilitar la biometría y otros métodos de autenticación sin contraseña.