La Trampa de la Reescritura

Rate this content
Bookmark

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.

22 min
09 Mar, 2023

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

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

TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Top Content
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️

Workshops on related topic

React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
JSNation 2023JSNation 2023
57 min
0 To Auth In An Hour For Your JavaScript App
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.js backend + Vanilla JS frontend) to authenticate users with One Time Passwords (email) and OAuth, including:
- User authentication – Managing user interactions, returning session / refresh JWTs- Session management and validation – Storing the session securely for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
JSNation 2023JSNation 2023
87 min
Build a Collaborative Notion-Like Product in 2H
WorkshopFree
You have been tasked with creating a collaborative text editing feature within your company’s product. Something along the lines of Notion or Google Docs.
CK 5 is a feature-rich framework and ecosystem of ready-to-use features targeting a wide range of use cases. It offers a cloud infrastructure to support the real-time collaboration system needs. During this workshop, you will learn how to set up and integrate CK 5. We will go over the very basics of embedding the editor on a page, through configuration, to enabling real-time collaboration features. Key learnings: How to embed, set up, and configure CK 5 to best fit a document editing system supporting real-time collaboration.
Table of contents:- Introduction to the CK 5 ecosystem.- Introduction to a “Notion-like” project template.- Embedding CK 5 on a page.- Basic CK 5 configuration.- Tuning up CK 5 for a specific use case.- Enabling real-time editing features.