Luchando contra la Deuda Técnica con Refactorización Continua

Rate this content
Bookmark

Afrontémoslo: la deuda técnica es inevitable y reescribir tu código cada 6 meses no es una opción. La refactorización es un tema complejo que no tiene una solución única. Las aplicaciones frontend son particularmente sensibles debido a los frecuentes cambios en los requisitos y flujos de usuario. Nuevas abstracciones, patrones actualizados y limpiar esas funciones antiguas: todo suena genial en teoría, pero a menudo falla en la práctica: las tareas se acumulan, los tickets terminan pudriéndose en el backlog y el código heredado aparece en cada rincón de tu base de código. Por lo tanto, un proceso de refactorización continua es la única arma que tienes contra la deuda técnica. En los últimos tres años, he estado explorando diferentes estrategias y procesos para refactorizar código. En esta charla describiré los componentes clave de un marco para abordar la refactorización y compartiré algunos de los aprendizajes acumulados en el camino. Espero que esto te ayude en tu búsqueda de mejorar la calidad del código de tus bases de código.

29 min
02 Dec, 2022

Video Summary and Transcription

Esta charla discute la importancia de la refactorización en el desarrollo y la ingeniería de software. Presenta un marco llamado los tres pilares de la refactorización: prácticas, inventario y proceso. La charla enfatiza la necesidad de prácticas claras, comprensión de la deuda técnica y un proceso bien definido para una refactorización exitosa. También destaca la importancia de la visibilidad, la recompensa y la resiliencia en el proceso de refactorización. La charla concluye discutiendo el papel de la propiedad, la gestión y la priorización en la gestión de la deuda técnica y los esfuerzos de refactorización.

Available in English

1. Introducción y Antecedentes

Short description:

Hola a todos. Es una vista tan agradable estar frente a un escenario después de tanto tiempo. Ya he estado aquí antes. Lo pasé muy bien. Como dijo Yanni, mi nombre es Alex. Trabajo en Code Sandbox. Estoy organizando JS Heroes. Nuestro próximo evento es en mayo de 2023. Hoy quiero hablar sobre refactorización. Pero antes de comenzar, hay este enlace en la parte inferior. Bit.ly slash Alex refactorización. Pueden encontrar las diapositivas allí. También pueden encontrarme en Twitter en Alex and Moldovan. Eso es prácticamente todo.

Hola a todos. Es una vista tan agradable estar frente a un escenario después de tanto tiempo. Tienen que disculpar mi voz, el clima de Berlín no fue amable con ella esta semana, desafortunadamente. Pero es una gran ciudad. Ya he estado aquí antes. Estuve aquí en esta conferencia en 2018. Lo pasé muy bien.

Oh, sí. Así que comencemos. Como dijo Yanni, mi nombre es Alex. Vengo de Rumania. Trabajo en Code Sandbox. ¿Alguien aquí usa Code Sandbox? Genial. Alex. Buen público. Genial. También, como se mencionó, estoy organizando JS Heroes. Este es un evento de la comunidad basado en Cluj, Rumania. Nuestro próximo evento es en mayo de 2023. Espero ver a algunos de ustedes allí también. Encuéntrenme después de la charla. Podemos hablar más si están interesados en esto.

Así que hoy quiero hablar sobre refactorización. Pero antes de comenzar, hay este enlace aquí en la parte inferior. Bit.ly slash Alex refactorización. Pueden encontrar las diapositivas allí si quieren seguirlas o si quieren encontrarlas más tarde. Ya están en línea. Y también estarán después de la charla. También pueden encontrarme en Twitter en Alex and Moldovan, mientras la plataforma con suerte todavía esté funcionando. Así que sí, eso es prácticamente todo.

2. Why I want to talk about refactoring

Short description:

Quiero hablar sobre la cultura de refactorización. Me fascina por qué no hemos descubierto cómo refactorizar nuestro código sin afectar el desarrollo del producto. Podemos construir equipos y culturas de ingeniería en torno a la introducción de la refactorización como cualquier otra tarea. Entendiendo que está bien vivir con deuda técnica, necesitamos gestionarla. Presentaré un marco llamado los tres pilares de la refactorización: prácticas, inventario y proceso.

Por qué quiero hablar sobre refactorización o por qué se trata esta charla de refactorización. Quiero hablar sobre la cultura de refactorización. No estoy aquí para decirles formas de refactorizar código o técnicas para mejorar su código o mejorar sus componentes de React o el frontend en general. Me fascina principalmente por qué no hemos descubierto cómo refactorizar nuestro código, nuestras bases de código sin afectar realmente el desarrollo del producto.

He trabajado con muchos equipos diferentes en los últimos años y especialmente con equipos de productos. Siempre ha existido este problema de, bueno, hemos acumulado deuda técnica, ahora es el momento de hacer refactorización. Así que, ya saben, los gerentes de proyectos, por favor, háganse a un lado. Es hora de que los ingenieros tomen el escenario y trabajen durante un mes reescribiendo todo, introduciendo un nuevo marco o lo que sea para resolver esta deuda técnica. Creo que podemos hacerlo mejor. Creo que podemos construir nuestros equipos de ingeniería y nuestras culturas de ingeniería en torno a la introducción de la refactorización y tratarla como cualquier otra tarea en un proyecto.

Y esto se hizo aún más claro para mí hace unos meses cuando introdujimos esta nueva cosa en la base de código de Code Sandbox. Entonces, tenemos esta cosa llamada proveedor de pitcher. Pitcher es nuestro motor para ejecutar el editor. Entonces, cuando ejecutas el editor de Code Sandbox, tienes esta cosa de pitcher que te sirve todos los datos del VM. Y hemos introducido una nueva forma de consumir los datos de pitcher. Así que ahora tenemos un proveedor de pitcher heredado y un proveedor de pitcher, ¿verdad? Y eso está perfectamente bien. Nunca dijimos, bueno, ahora tenemos que detener todo en Code Sandbox y tenemos que enfocarnos en deshacernos de la forma antigua porque tenemos una nueva forma de consumir datos. Y creo que esto es realmente valioso. Entendiendo que está bien vivir con deuda técnica. No tienes que sentirlo necesariamente como una carga. Pero sí tienes que gestionarlo. En realidad, esto sucedió mientras me preparaba para esta charla. Y mientras también hacía eso, me di cuenta de que tal vez el título está equivocado. Tal vez no debería ser luchar contra la deuda técnica, sino más bien gestionar la deuda técnica. Entonces, lo que voy a mostrarles en los próximos minutos es un marco de cómo creo que podemos gestionar la deuda técnica en equipos de ingeniería. Y lo llamo los tres pilares de la refactorización. Porque, bueno, obviamente tiene tres pilares. Uno son las prácticas, otro es el inventario y otro es el proceso. Y los voy a explicar uno por uno y explicar qué quiero decir con ellos. Así que, primero, tenemos las prácticas.

3. Goal, Practices, and Inventory

Short description:

Tu objetivo es alcanzar una cierta arquitectura y tener una forma de componer componentes y consumir un sistema de diseño. Establece prácticas y pautas de codificación para estructurar el código y documentar la forma de trabajo de tu equipo. El inventario a menudo se pasa por alto pero es crucial. Implica recopilar datos, registrar la deuda técnica y priorizar soluciones en un documento separado llamado contabilidad de la deuda técnica.

Este es tu objetivo. Desde la perspectiva de ingeniería. Quieres alcanzar una cierta arquitectura. Quieres tener una cierta forma de componer tus componentes. Quieres tener una forma de consumir un sistema de diseño, por ejemplo.

Entonces aquí tienes todos tus patrones y tu arquitectura. Puedes dibujar tus diagramas, documentar cómo trabaja el equipo de ingeniería, cómo piensan de manera muy general acerca de hacia dónde quieren que vaya la base de código. Pero también profundizas, te sumerges cada vez más en términos de abstracción.

Entonces puedes tener en tus prácticas, ¿cómo estructuras normalmente el código? ¿Creas carpetas para cada componente? ¿Divides los archivos por función? ¿Divides los archivos por característica? ¿Cómo estructuras tu código en general? Y aún más abajo, a nivel de código, puedes tener tus pautas de codificación. Y no estoy pensando necesariamente en cosas que se puedan automatizar, sino en patrones que tú y tu equipo descubren, hey, hay tres formas, y como mostró Nick, hay tres formas de hacer algo. Especialmente con React. Elijamos una. Tengamos documentada nuestra forma de trabajar. Usamos Code Sandbox, estas pautas generales de codificación que tenemos internamente y que referenciamos en todas las PR.

Entonces, cada vez que haya una discusión en una PR, como ¿deberías componer componentes de esta manera o de aquella? Oh, sí, en realidad hay una pauta para eso. Si no hay una pauta para eso, ahora es un buen momento para agregarla allí. Entonces, estas son prácticas, ¿verdad? Esto es... Como que te da el punto de referencia de lo que quieres lograr con tu proceso de refactorización. Y ahora pasamos al inventario, que puede ser el más importante y el más pasado por alto.

En mis experiencias anteriores con diferentes equipos, noté que mucha gente trata esto de manera bastante superficial. El inventario se trata de recopilar todos los datos. ¿Qué sucede en la base de código? ¿Qué tan lejos estamos del resultado deseado, verdad? Entonces se trata de registrar cosas, digamos, en el backlog. Eso es algo que probablemente sea lo más común cuando las personas tienen una deuda técnica que saben que quieren refactorizar. Probablemente crearán un ticket.

Lo que notamos con los tickets del backlog en Code Sandbox es que tienden a quedarse ahí en el backlog porque nadie los revisa. Así que comenzamos una nueva cosa llamada contabilidad de la deuda técnica, que es un documento separado al que hacemos referencia, nuevamente, en las PR. Cada vez que una PR, digamos, introduce una deuda técnica debido a diferentes razones, como falta de tiempo o simplemente aún no tenemos la abstracción para algo, decimos, OK, pongamos esto en el documento de contabilidad de la deuda técnica. Expliquémoslo allí. ¿Por qué introdujimos la deuda técnica? ¿Cuál es una posible solución para ello? ¿Quién es el responsable? No necesariamente quién lo resolverá, sino quién levantará la bandera de que, hey, esto es importante y aún no lo hemos resuelto? Y luego, finalmente, le asignamos una prioridad. Y esto también forma parte del proceso de inventario.

4. Assigning Priority and Planning

Short description:

No toda la deuda técnica es igual. Un ejemplo divertido de esto es un componente que construimos hace más de un año. Es un renderizador de markdown para Code Sandbox. Nunca nos molestamos en refactorizarlo porque funciona y no ha sido modificado. Una vez que tengas tus prioridades claras, comienza a planificar la deuda técnica importante utilizando documentación como RFC. Sigue el plan pero no detengas otros procesos.

Asignar prioridad. Porque no toda la deuda técnica es igual de alguna manera. Y tengo un ejemplo divertido de esto. Hace más de un año construimos este componente un viernes. Yo y un colega. Queríamos construir este renderizador de markdown para Code Sandbox. Así que cada vez que abres un archivo de markdown, en lugar de ver el código markdown, también puedes ver una vista previa de cómo se ve ese markdown.

Así que nos llevó tres o cuatro horas, pusimos allí un montón de dependencias, bibliotecas que hacen todo el trabajo. Solo conectamos cosas. Agregamos algunos complementos. Así que tiene alguna funcionalidad personalizada. Como, ya sabes, puedes seguir rutas, abrir archivos y cosas así. Pero nunca nos molestamos en refactorizar esto. ¿Por qué? Porque este archivo no ha sido modificado desde entonces. Simplemente funciona, ¿verdad? Entonces, si funciona, ¿por qué necesitarías tocarlo? Porque este archivo es como que vive en la periferia de la base de código. No es algo que los desarrolladores abran a diario y tengan que luchar con él y pasar por él y entender qué está sucediendo allí. Simplemente lo tomas como una caja negra. Oh, sí, ese es un componente. Funciona. Si y cuando esto se convierta en un problema, comenzaremos a darle una mayor prioridad en términos de deuda técnica. Pero hasta entonces, probablemente tengamos otras cosas más importantes que abordar.

Y finalmente, una vez que tengas tus prioridades claras, puedes comenzar a planificar un poco. También es parte del paso de inventario. Es muy importante decir, bueno, y especialmente para las cosas más complejas. No estoy diciendo aquí que debas planificar cuando quieras cambiar el nombre de algo o cuando quieras limpiar un poco de código. Pero más bien, para las deudas técnicas más importantes que son realmente complicadas y tal vez se extiendan durante varios meses, puedes tener algo como RFC o cualquier tipo de documentación que te permita planificar con anticipación y compartirlo con todos para que todos tengan una comprensión común de que, hey, tenemos esta deuda técnica, aquí está el plan de cómo vamos a resolverlo. Va a tomar lo que sea. Tres meses, seis meses. No importa realmente. Vamos a tratar de seguirlo, pero no vamos a detener ningún otro proceso.

5. Refactoring Framework and Rules

Short description:

Para refactorizar con éxito, es necesario tener prácticas claras, comprender la deuda técnica y contar con un proceso bien definido. Estos tres pilares forman un marco para la refactorización efectiva. Sin los tres pilares, la refactorización se vuelve desafiante y menos metódica. En la segunda parte de la charla, proporcionaré ejemplos de reglas que el equipo de ingeniería de Code Sandbox sigue para lograr una refactorización exitosa. La primera regla es hacer visible el proceso de refactorización.

Esto no nos va a bloquear porque tenemos un plan para mitigar esta deuda. Para resumir estos dos primeros pilares de los que hablamos, es casi como dije, las prácticas son tu objetivo. Entonces dices, está bien, aquí es donde queremos llegar eventualmente. Y luego, con el inventario, dices, oh sí, estamos aquí ahora. Estamos a esta distancia de esta buena idea, buena solución o buena arquitectura a la que queremos llegar. Y no estoy diciendo perfecto porque no necesariamente debes apuntar a la perfección aquí. Y luego el inventario te dará esta especie de brecha, te mostrará, oh sí, estás a esta distancia de tu objetivo. Así que ahora es el momento de aplicar el proceso y refactorizar las cosas y simplemente tomar el tiempo, tomar el plan por delante y manejar todos estos cambios. Entonces, si haces estas dos cosas antes, si tienes tus prácticas claras, si tienes tu inventario, si sabes cuál es la deuda técnica, entonces el proceso es prácticamente lo mismo que cualquier otra tarea, ¿verdad? La única diferencia es que esta vez son los ingenieros los que te dan este análisis antes, ¿verdad? De la misma manera que los gerentes de proyecto lo harán, o los analistas de negocios harán el análisis del producto por adelantado y dirán, está bien, tenemos que entregar esta función, tendrá este impacto o funcionará para estos usuarios de esta manera, de la misma manera tienes tu proceso para esas tareas y de la misma manera para la refactorización. Si haces esas cosas por adelantado, simplemente haces prácticamente todo lo que haces en una tarea regular. Tienes la ejecución, tienes cierta responsabilidad, alguien se asigna a algunas tareas, lleva algún tiempo, tiene algunas estimaciones, tienes algún progreso, tienes una definición de hecho, cuándo se terminará esta tarea. Así que aquí está una visión general de todo, solo como un resumen rápido, mientras tal vez tomo un sorbo de agua aquí. También encontré muy importante tratar de visualizarlos tal como son. Y también, tal vez una cosa que me olvidé mencionar aquí, es muy difícil hacer la refactorización de manera metódica si no tienes los tres pilares. Por eso lo llamo un marco para construir esto. Piénsalo. Si no tienes las prácticas en su lugar, ¿qué estás haciendo? Lo más probable es que los ingenieros simplemente estén refactorizando porque les gustan ciertos patrones, pero no es el terreno común al que apunta el equipo. No es algo en lo que te hayas establecido. Si no tienes el inventario, puedes tener las prácticas. Sabes a dónde quieres llegar, pero no tienes idea de cuál es tu deuda técnica. ¿Qué estás realmente resolviendo o tal vez refactorizando en vano? Por supuesto, no puedes hacerlo sin el proceso real, que es hacer los cambios reales que deseas hacer. Correcto. Ya hemos pasado por esto. Ahora, en la segunda parte de la charla, quiero darte un par de ejemplos de cosas que hacemos actualmente con el equipo de ingeniería de Code Sandbox. Las llamo reglas para que esto funcione. Porque estoy seguro de que estás pensando, está bien, esto es muy teórico y tal vez no se aplica a mi proyecto o mi contexto. Pero creo que con un par de ejemplos de cosas que los equipos pueden hacer, creo que se volverá un poco más claro. Y las llamo reglas para que funcione, porque se siente como si necesitaras ciertas reglas para guiarte a través de todo el proceso. Y la primera es hacerlo visible.

6. Visibilidad, Recompensa y Resiliencia

Short description:

Un gran problema con la refactorización es la idea errónea de que debe hacerse en secreto. En un equipo metódico, la visibilidad es crucial. Tener tickets separados para la refactorización en tu herramienta de gestión de proyectos. Hacer PRs separados para la refactorización. La segunda regla es hacer que la refactorización sea gratificante y celebrada. Celebra la eliminación de código e involucra a todo el equipo. Deshazte del código que no genera alegría. Haz que el proceso de refactorización sea resiliente.

Un gran problema que tengo con la refactorización en general es que hay esta preconcepción de que la refactorización debe hacerse en secreto. Los ingenieros simplemente agregan algunos commits al final de un PR solo para mejorar un poco el código. Y eso solía ser una buena práctica. Pero realmente creo que en un equipo más metódico donde realmente quieres seguir un plan, necesitas hacer que todas estas cosas sean visibles. Así que sí.

Ten tickets claramente separados en tu herramienta de gestión de proyectos donde digas, quiero... Durante este ciclo, durante este sprint, cualquier proceso que estés utilizando, vamos a manejar estas cosas que son refactorización de deuda técnica o lo que sea. También haz PRs separados para la refactorización. Por ejemplo, si incluyes cambios en tus PRs de producto que son refactorizaciones de código, en primer lugar estás haciendo que sea más lento integrar nuevas características porque ahora la revisión de código puede ser el doble de complicada debido a que hay más cambios en el PR. Pero también, si lo piensas, deberías ver de manera diferente un PR que maneja cambios en el producto en comparación con un PR que maneja refactorización. Debería ser un objetivo diferente y el nivel de revisión debería ser ligeramente diferente.

La segunda regla es hacer que sea gratificante para el equipo. Necesitas contar con la participación de todos en el equipo de ingeniería. Lo que significa que debes asegurarte de que sea fácil contribuir a cualquier esfuerzo de refactorización. También es gratificante. También se celebra. La refactorización puede ser bastante desafiante, porque la mayoría de las veces no es realmente el trabajo más glorioso que tienes que hacer. Así que lo que hacemos es celebrarlo. Cada vez que eliminamos código, decimos, sí, lo hicimos. Y todo el equipo celebra. Es prácticamente la misma sensación que cuando se lanza una función importante, porque se ha lanzado algo en tu hoja de ruta, se ha lanzado algo de esta hoja de ruta de refactorización que tienes en paralelo a la hoja de ruta del producto. Y también una cosa que comenzamos recientemente es deshacernos del código que no genera alegría. Ahora tenemos esta cosa, de vez en cuando, llamamos a la Marie Kondo del código base, donde nos reunimos con el equipo de ingeniería un viernes en nuestra oficina virtual y comenzamos a desmontar cosas del código, cosas que no necesitamos o simplemente cosas que en general se pueden reescribir. Nos tomamos el tiempo y realmente celebramos esto. Incluso ahora lo tenemos de manera muy formal, recopilamos todas estas ideas mensualmente y decimos, oh, para el próximo mes, nos ocuparemos de estas cosas. Tal vez surjan cosas durante el mes y decimos, sí, hagámoslo durante el viernes de Marie Kondo. Así que se convirtió en algo desde hace unos meses. La última cosa es hacer que sea resiliente. No solo necesitas hacerlo visible, necesitas hacerlo gratificante, sino que también necesitas ser consciente de que al final del día no es la entrega del producto. La entrega del producto probablemente tendrá una prioridad más alta y probablemente tienda a dejar otras cosas de lado, ¿verdad? Entonces, cuando eso sucede, cuando tienes un plazo ajustado y todo, necesitas asegurarte de que el proceso sea resiliente.

7. Propiedad y Cultura de la Refactorización

Short description:

Incluso si está en baja prioridad, incluso si requiere poco esfuerzo, aún está presente, ¿verdad? Tenemos reuniones semanales de ingeniería con todo el equipo para discutir la salud del código y plantear cualquier preocupación sobre la deuda técnica. Asignar propietarios a estos esfuerzos es crucial, incluso durante períodos ocupados. Idealmente, alguien en el equipo debería asumir la responsabilidad del proceso de refactorización más grande. Cada equipo tiene a alguien que impulsa la cultura de la refactorización, y si no sabes quién es, probablemente seas tú. Muchas gracias y feliz refactorización.

Incluso si está en baja prioridad, incluso si requiere poco esfuerzo, aún está presente, ¿verdad? No pierdes de vista eso. No dejas que la deuda técnica abrume todo.

Lo que hacemos es tener estas reuniones semanales de ingeniería con todo el equipo. No importa si eres parte de alguno de los equipos de producto dentro de la empresa. Vienes a esta reunión y no hay discusión sobre entregas. No hay discusión sobre lanzamientos. Solo hablamos sobre la salud del código. Solo hablamos sobre cualquier cosa relacionada con DX que levantemos, ¿verdad? Si tenemos deuda técnica que no se aborda y tiene alta prioridad en nuestro documento y cosas así. No solo hablamos de ello. Por supuesto, también tomamos notas, ¿verdad? Asignamos propietarios a las cosas. Alguien tiene que asumir la responsabilidad. Alguien tiene que llevar la bandera. Incluso si estamos pasando por un período difícil en el que necesitamos entregar de manera continua, hacemos un seguimiento de estos esfuerzos. Incluso si solo está en el fondo de nuestras mentes.

Y como la última pregunta, si tienes personas que son propietarias de diferentes partes del proceso de refactorización, ¿quién es el propietario del proceso más grande? Y creo que idealmente alguien en el equipo debería asumir ese rol. Y espero que esta charla o algunas de las ideas que compartí aquí te animen a ser esa persona en tu equipo. Y adapté esta cita. Pero digo que cada equipo tiene a alguien que impulsa la cultura de la refactorización... Lo siento, cada equipo tiene a una persona. Y si no sabes quién es, probablemente seas tú.

Muchas gracias y feliz refactorización. Muchas gracias. Muchas gracias, Alex. ¿Tomarías asiento? Una charla tan importante, importante. Personalmente me encuentro actualmente con mucha deuda técnica, pero mi único consuelo es que yo escribí la deuda técnica, así que solo puedo odiarme a mí mismo. Muy bien, creo que la risa significa que probablemente se acabaron las preguntas, y hay una pregunta realmente buena con la que creo que debemos comenzar. Mostraste el PR donde eliminaste, ya sabes, miles de líneas de código. ¿Cómo explicas el valor de esto a Elon Musk? Y tal vez más específicamente, creo que la pregunta es... La gestión tiene una visión diferente de la deuda que la ingeniería. Para la ingeniería y las personas normales, la deuda es mala.

8. Gestión de la Deuda Técnica con la Dirección

Short description:

La deuda es un recurso para la dirección, pero es importante tener una conversación con la alta dirección sobre las consecuencias de acumular deuda técnica. Mostrar métricas de productividad puede ayudarles a comprender el impacto en la velocidad del equipo. Elija un problema específico y demuestre cómo afecta a la productividad. Hacer un gran cambio puede complacer a personas como Elon Musk que quieren ver mucho código escrito.

Pero para la dirección, la deuda es un recurso. Te ayuda a avanzar más rápido, te ayuda a hacer las cosas. Entonces, ¿cómo tienes esta conversación con la alta dirección si es necesario, donde tu equipo de ingeniería tiene una concepción ligeramente diferente de ella que la dirección tiene? Sí. Creo que este es un tema complicado porque personalmente... Siento que estoy en una posición privilegiada porque nuestro fundador es técnico, así que entiende esas cosas, y estoy seguro de que hay equipos en los que es un poco más difícil hacerlo. No sé si simplemente mostrar métricas funciona en este caso, pero en general explicar... Supongo que las personas que realmente no entienden las consecuencias de acumular deuda técnica probablemente lo entenderán si solo muestras algunas métricas de productividad, ¿verdad? El equipo es más lento porque tienen que ocuparse de un fragmento de código que molesta a todos, ¿verdad? Esas son las cosas que, por ejemplo, intentamos solucionar con los esfuerzos de Marie Kondo, ¿verdad? Oh, está este molesto componente de enrutador que tenemos que revisar a diario y tiene algunas importaciones aleatorias y tenemos que solucionarlo. O está este componente de diseño muy extraño que renderiza todas las subpartes de la aplicación y siempre nos molesta porque nunca podemos encontrar algo ahí. Entonces, elegiría una cosa y simplemente mostraría lo malo que es para la productividad. Solo mostrar, incluso mostrar una grabación de alguien haciendo un pequeño cambio y lo difícil que es encontrar lo que necesitan cambiar. Sí, es un muy buen punto. Y además, creo que a Elon Musk le gustará cuando hagas un gran cambio porque solo quiere ver mucho código escrito. Sí. Ya sabes. Sí, exactamente. ¿Cómo entendería él el código de todos modos? Así es. Aliméntalos con basura y mantenlos en la oscuridad, ¿no es así? Ya sabes, cómo lo hacemos. Sí, exactamente. Correcto.

9. Priorización de la Deuda Técnica y la Refactorización

Short description:

No hay un número específico de cuánto tiempo se debe asignar a la refactorización en un equipo de ingeniería. Varía de un equipo a otro. Sin embargo, es beneficioso si todos en el equipo participan en la refactorización. Esto distribuye la carga de trabajo y asegura que todos contribuyan tanto a la refactorización como al desarrollo del producto. Tener un proceso establecido, como documentar y crear tickets, puede facilitar que el equipo priorice y contribuya a los esfuerzos de refactorización.

Muy bien. Hay varias preguntas sobre la priorización. Y creo que lo mencionaste al final. Pero creo que lo que todos realmente quieren saber es cómo se prioriza la deuda técnica y cuánto tiempo se le asigna. En un equipo de ingeniería. Y entiendo que esto será diferente para cada equipo y para cada ciclo de vida del producto. Pero, ¿hay un número que se pueda llevar a casa y decir a los jefes que Alex Moldovan de Code Sandbox dijo que deberíamos pasar al menos el 70 por ciento de nuestro tiempo en refactorización? Sí. No quiero que me demanden más tarde por dar números falsos. Creo que varía de equipo a equipo. Y también, lo que encontré útil es que si todos en el equipo lo hacen, no se siente como si alguien lo estuviera haciendo. Sabes, es solo una distribución. No es como si una persona de nuestro equipo de seis estuviera haciendo refactorización todos los días y las otras cinco solo estuvieran desarrollando el producto. Es más como si los seis ingenieros estuvieran trabajando. Y también están entregando cosas en el producto. Así que realmente no tienes que pensar que una persona está fuera de la ecuación porque están haciendo el trabajo pesado de refactorización. Pero sí necesitas tener las cosas por adelantado. Como, entiendo que lleva tiempo, por ejemplo, documentar las cosas y lleva tiempo incluso crear un ticket, digamos. Entonces, si tienes el proceso establecido, es mucho mejor. Si ya tienes todas las cosas por adelantado, entonces simplemente señalar otra deuda técnica que se incluyó o cualquier otra cosa se vuelve más fácil. La barrera de entrada es más baja para contribuir al esfuerzo. Sin duda.

QnA

Refactorización con PR y Cobertura de Pruebas

Short description:

Sugiero mostrar este video de la charla a tus jefes. La refactorización con PR puede ser difícil, especialmente en procesos de entrega complejos. Un enfoque es mantener los PR de refactorización activos durante más tiempo y fusionarlos después de importantes lanzamientos o pruebas de calidad. Las ramas de larga duración pueden ayudar a gestionar el trabajo de refactorización. La cobertura de pruebas es crucial para una refactorización segura, proporcionando certeza y permitiendo que los cambios se propaguen. Una variedad de pruebas, incluyendo pruebas unitarias, son importantes para la refactorización.

Y aunque no obtuvimos un número de Alex, sugiero que muestres este video de la charla a tus jefes. Creo que al menos será un buen punto de partida para la conversación.

Tenemos un par de preguntas más. Sé que evitaste los temas técnicos aquí, pero la pregunta más popular es un poco técnica, si me permites. Sí. La refactorización con PR puede ser difícil. ¿Qué opinas sobre el desarrollo basado en tronco, el uso de flags de características, etc.? ¿Existen alternativas al flujo estándar de PR de GitHub que puedas usar para facilitar la refactorización? Puedes pensar ahora en algo en particular. Creo que probablemente se vuelve más complicado cuando tienes un proceso de entrega más complejo. Si necesitas lanzar semanalmente o cada dos semanas, o estás trabajando en una rama RC, entonces tienes que averiguar cuándo incluir este trabajo de refactorización en él. La mayoría de las veces, lo que hice en el pasado, y no solo con lo actual sino en general, es que los PR de refactorización estuvieron activos durante más tiempo. No es como si hiciéramos la refactorización, alguien la aprobara y la fusionáramos inmediatamente, era más como `hey, estamos trabajando en esto`. Lo mantenemos durante más tiempo hasta asegurarnos de que sea el momento adecuado para fusionarlo. Tal vez sea justo después de un lanzamiento importante cuando terminamos con las correcciones de errores o la parte de pruebas de calidad antes del lanzamiento. Así que realmente no afecta la entrega. Tal vez esa sea la mejor respuesta por ahora. Solo ramas de larga duración que... Por supuesto, sé que probablemente sea más difícil porque pueden haber conflictos y cosas así. Pero aún así, es mucho mejor que no tener estas ramas de refactorización en absoluto.

Y creo que hay una pregunta relacionada. Voy a elegir una. ¿Podrías compartir rápidamente tu opinión sobre cómo se relacionan la cobertura de pruebas y la cultura de refactorización? Porque, obviamente, las pruebas facilitan la refactorización, pero a veces también la dificultan porque también tienes que refactorizar las pruebas a medida que avanzas en el núcleo. Cierto. Sí, de hecho tenía una diapositiva sobre eso y la eliminé porque sentí que no encajaba realmente con las demás cosas. Pero en algún momento quería hablar sobre cómo hacer que todo este proceso sea seguro. En mi opinión, las pruebas son súper importantes, son cruciales para esto porque no tienes certeza si no tienes las pruebas adecuadas y digamos, type safety. Si no tienes type safety, es muy difícil refactorizar las cosas, especialmente a medida que la aplicación se vuelve más grande. Creo que esto fue lo primero que se me vino a la mente, como, oh, por qué, TypeScript es tan increíble porque ahora puedo simplemente comenzar a cambiar algo y debería propagarse en todos los archivos donde fallaba la compilación. Y con las pruebas, creo que es súper importante tener una variedad de pruebas para la refactorización. Si solo tienes pruebas unitarias, la mayoría de las veces cuando refactorizas, también tendrás que mejorar esas pruebas unitarias.

Refactoring versus Rewriting

Short description:

Si tienes pruebas de integración y pruebas end-to-end para complementar eso, entonces esas deberían convertirse en tu ancla. Siempre intenta refactorizar y evolucionar la arquitectura y la base de código en lugar de comenzar desde cero. Por favor, habla con Alex en la sala de preguntas y respuestas de los ponentes para más preguntas.

Si tienes pruebas de integración y pruebas end-to-end para complementar eso, entonces esas deberían convertirse en tu ancla, ¿verdad? Y asegúrate de que esas sigan funcionando mientras las otras se reescriben. Sí, eso es absolutamente cierto.

Así que tenemos tiempo para una pregunta final. En realidad, tenemos muchas preguntas, así que por favor habla con Alex en la sala de preguntas y respuestas de los ponentes después. Pregunta final, muy rápidamente, refactorización versus reescritura, ¿cuáles son tus pensamientos? Siempre intentando refactorizar. La reescritura, creo que pasamos por un período de tiempo, como Nick mostró antes, como el período temprano del desarrollo front-end cuando era mejor reescribir porque estas prácticas, estas best practices se reinventaban mensualmente. Siento que ahora estamos en un entorno más estable con el desarrollo front-end. Algunos podrían argumentar que no lo estamos, pero yo diría que somos mucho más estables que lo que sucedió hace 10 años. Siempre abogaría por la refactorización y la evolución de la arquitectura, la evolución de la base de código en lugar de una revolución de simplemente desecharlo todo y comenzar desde cero. Absolutamente.

Bueno, eso es todo lo que tenemos tiempo para aquí en el escenario, pero todas estas preguntas aquí son geniales, bueno excepto esa, pero la mayoría de ellas son geniales, así que por favor habla y conversa con Alex en la sala de preguntas y respuestas de los ponentes. Muchas gracias Alex por unirte a nosotros y nos vemos pronto. Sí. Gracias.

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

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Summit 2022React Summit 2022
27 min
Impact: Growing as an Engineer
Top Content
Becoming a web engineer is not easy, but there are tons of resources out there to help you on your journey. But where do you go from there? What do you do to keep growing, and to keep expanding the value you bring to your company? In this talk we’ll look at the different kinds of impact you can have as a web engineer. We’ll walk through what it means to take on bigger, more complex projects, and how to scale yourself, and grow the community around you. By driving our own development we can all grow our impact, and in this talk, we’ll discuss how to go about this.
React Day Berlin 2022React Day Berlin 2022
22 min
Jotai Atoms Are Just Functions
Top Content
Jotai is a state management library. We have been developing it primarily for React, but it's conceptually not tied to React. It this talk, we will see how Jotai atoms work and learn about the mental model we should have. Atoms are framework-agnostic abstraction to represent states, and they are basically just functions. Understanding the atom abstraction will help designing and implementing states in your applications with Jotai
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 Summit 2023React Summit 2023
26 min
Principles for Scaling Frontend Application Development
After spending over a decade at Google, and now as the CTO of Vercel, Malte Ubl is no stranger to being responsible for a team’s software infrastructure. However, being in charge of defining how people write software, and in turn, building the infrastructure that they’re using to write said software, presents significant challenges. This presentation by Malte Ubl will uncover the guiding principles to leading a large software infrastructure.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)