Un marco para gestionar la deuda técnica

Spanish audio is available in the player settings
Rate this content
Bookmark
Slides

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 viejas funciones: todo suena genial en teoría, pero a menudo falla en la práctica: los pendientes 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.



35 min
09 Mar, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

La charla de hoy analiza la importancia de gestionar la deuda técnica a través de prácticas de refactorización, priorización y planificación. La refactorización exitosa requiere establecer pautas, mantener un inventario e implementar un proceso. Celebrar el éxito y garantizar la resiliencia son clave para construir una cultura sólida de refactorización. La visibilidad, el apoyo y la comunicación transparente son cruciales para abordar la deuda técnica de manera efectiva. Las responsabilidades del equipo, el estilo de operación y la disponibilidad deben ser transparentes para los gerentes de producto.

Available in English

1. Introducción a la Refactorización y Deuda Técnica

Short description:

Mi nombre es Alex y me uno desde Rumania, desde una ciudad llamada Cluj. El tema de hoy es un marco para gestionar la deuda técnica. Quiero hablar sobre la cultura de refactorización y los tres pilares de la refactorización.

Hola a todos, gracias por unirse a esta sesión. Mi nombre es Alex y me uno desde Rumania, desde una ciudad llamada Cluj, que se encuentra en el hermoso corazón de Transilvania, donde trabajo como ingeniero frontend en CodeSandbox y, además, soy el fundador de JS Heroes, nuestra comunidad local que organiza los encuentros locales aquí en Cluj y también la conferencia JS Heroes que se celebra cada primavera. También pueden encontrarme en Twitter en alexandmodovan y el tema de hoy es un marco para gestionar la deuda técnica.

Y quería hablar sobre la deuda técnica desde hace un tiempo y básicamente esta charla también no solo trata sobre la deuda técnica, que es inevitable para todos los proyectos, para todos los equipos de ingeniería sino también se trata de la refactorización. No voy a hablar necesariamente sobre cómo refactorizar código o sobre algunos patrones para hacer refactorización. Estoy aquí para hablar un poco más sobre la capa más meta, si quieres, y quiero hablar sobre la cultura de refactorización, porque he estado trabajando durante los últimos cinco o seis años con diferentes equipos de productos, diferentes equipos de ingeniería, equipos verticales, equipos horizontales, equipos de plataforma y siempre me pareció extraño que nunca logramos hacer bien la refactorización. Como industria, todavía tenemos mucho este problema.

En realidad, pocas personas hablan de esto en general, así que pensé en explorar algunas cosas. Desde que empecé a pensar más en esto, empecé a desarrollar este marco, o estructura, o más bien, cómo construir la estructura correcta alrededor de los procesos de refactorización Esto es a lo que me refiero como una cultura de refactorización. El detonante para esta charla en particular ocurrió hace algunos meses. Cuando estábamos trabajando en Code Samples, estábamos trabajando en este, digamos, pequeño experimento de refactorización donde introdujimos una nueva forma de comunicarnos con nuestro backend. Tenemos este backend de nuestro editor de código, al que llamamos picture, que maneja todas las primitivas de bajo nivel de lo que se puede considerar un editor de código. Como acceso al sistema de archivos o tareas o procesos y cosas así. Así que se nos ocurrió esta nueva forma de hacerlo. Y ahora básicamente tenemos dos formas de hacer lo mismo en la aplicación.

Así que tenemos un proveedor de picture heredado, que estaba en la parte superior de todo. Y luego dentro de él, tenemos algo llamado proveedor de picture. Y al ver este código al principio, al ver la PR que estaba introduciendo este cambio, al principio me hizo gritar, como, oh, no, esto no está bien. Solo estamos estropeando el código, vamos a vivir con esto para siempre. Y esto es como una mala práctica. Pero luego poco a poco empecé a entenderlo, en realidad esto está bien, ¿verdad? En ese momento no había forma posible de cambiar todo el código de la noche a la mañana, y simplemente usar la nueva forma de consumir datos. Así que tuvimos que admitir estas dos formas alternativas. Y esto me hizo darme cuenta de que, está bien, siempre y cuando tengamos un método para esto, siempre y cuando tengamos una comprensión clara, ya sabes, en todo el equipo de que así es como estamos manejando este proceso, está bien, ¿verdad? Esto es más como gestionar todo este problema, ahora tenemos esta deuda técnica, somos conscientes de ello, pero al mismo tiempo lo estamos gestionando. No estamos, ya sabes, deteniendo todo el desarrollo para centrarnos en esto. Estamos avanzando con todo nuestro desarrollo de funciones. Y al mismo tiempo, tenemos un plan para mitigar este problema. Así que básicamente esto es lo esencial, lo que quiero decir con esta charla, en lugar de luchar contra la deuda técnica, en lugar de estar en este proceso en el que cada vez que surge algo, cada vez que algo está mal, cada vez que, ya sabes, la base de código no refleja la calidad que queremos que tenga, detenemos todo el desarrollo del producto y le decimos a, ya sabes, tus gerentes de producto dicen, oh, necesitamos resolver esto porque es de mayor prioridad. Eso claramente termina convirtiéndose en un problema y una lucha para el desarrollo del producto porque ya no tienes, ya sabes, una forma confiable de simplemente enviar en un ciclo regular. Y al mismo tiempo, en lugar de hacer eso, ¿verdad?, en lugar de decir, okay, quiero erradicar toda la deuda técnica tan pronto como surja, estoy pensando en un marco para gestionar esto, ¿verdad? Para no verse limitado por ello, para no tener que caer en el otro extremo donde, oh, ya no estamos haciendo ninguna refactorización, solo nos enfocamos en las funciones y luego las cosas se acumulan, pero al mismo tiempo no ser tan reactivo ante esto, como cada vez que algo surge, tratamos de solucionarlo de inmediato. Así que este marco intenta poner en marcha todas estas cosas, ¿verdad? Y esto es lo que llamo los tres pilares de la refactorización, porque obviamente hay tres pilares, y los vamos a analizar en un momento.

2. Prácticas de Refactorización e Inventario

Short description:

El primer pilar son las prácticas, que implica establecer metas y pautas para el equipo. Es importante documentar estas prácticas y tomar decisiones juntos. El siguiente paso es evaluar el estado actual de la base de código e identificar la deuda técnica. Esto se puede hacer documentando las áreas que necesitan mejora y priorizando tareas. Por ejemplo, crear nuevos componentes o desaprobar los obsoletos. Es crucial tener un documento separado para rastrear la deuda técnica y no depender únicamente del backlog. Al hacer esto, se pueden establecer prioridades y abordar la deuda técnica de manera efectiva.

Entonces, el primero, o lo primero que haces es, o el primer pilar son las prácticas. El siguiente es el inventario, y el tercero es el proceso. Ahora, pueden sonar un poco abstractos, pero una vez que los explique todos, espero que tengan sentido para todos.

Así que vamos a tomarlos uno por uno. ¿De qué se trata las prácticas? Las prácticas se trata principalmente de establecer esa meta con el equipo, sentarse juntos y decir, en este equipo, en este equipo de ingeniería, así es como queremos hacer las cosas para este proyecto en particular, así es como queremos enfocarlo, esta es la architecture, estos son los patterns, estas son las pautas. Entonces, tienes, nuevamente, todas estas cosas, patterns y todo, tienes tu architecture.

Idealmente, también las tienes documentadas, por lo que una buena práctica para hacer un seguimiento de estas prácticas es documentarlas básicamente. Puedes tener, ya sabes, formas en las que quieres estructurar tus archivos y tus carpetas, ¿quieres estructurar por funciones, estructurar por características, todas estas cosas, cómo quieres componer componentes, cómo quieres crear componentes. De hecho, en Code Sandbox, tenemos este documento para lo que llamamos las pautas generales de codificación. Estas son cosas que no puedes automatizar realmente, ¿verdad? Son decisiones que surgen. Puedes imaginar que tienes una PR en algún momento y alguien se da cuenta, oye, hemos estado haciendo esta lógica, así es como abordamos las cosas para este tipo de problema. Documentemos esto como una práctica para que otros puedan leerlo y volver más adelante, podemos hacer referencia cruzada en otras PR y decir, oye, decidimos hace tres meses que vamos a nombrar las cosas de esta manera o que vamos a usar esta abstracción en particular de esta manera o si tienes esto, deberías extraerlo en un componente separado. Todas estas cosas que realmente no se pueden automatizar y no siempre son tan claras. Son más como, hay diferencias sutiles y hay cosas en las que tu equipo necesita decidir.

Entonces, las prácticas son como establecer esta estrella polar de dónde quieres que esté tu architecture, dónde quieres que estén tus patterns, ¿cuál es el estado deseado en el que debería estar la base de código o cuál es tu objetivo como equipo de ingeniería? Y luego el siguiente paso es, en mi opinión, super importante como el que más cosas faltan, creo que faltan, es como hacer un poco de casi como introspección en la base de código o investigación y averiguar qué nos falta, ¿verdad? ¿Cuál es la brecha hacia este ideal o hacia estas prácticas que tenemos en mente? Esto es lo que queremos lograr, pero ¿dónde estamos ahora? Como, esto es el inventario, tratar de averiguar qué falta, aquí es donde documentas, ¿cuál es tu deuda técnica? Sabes, ¿cuáles son las partes de la aplicación que necesitan ser actualizadas? Sabes, todas las cosas que necesitas, todos los pasos que necesitas seguir para llegar a ese escenario ideal. Entonces, podrías tener cosas en tu backlog, por ejemplo, comienzas a documentar, oye, tenemos tareas específicas para actualizar algo, para reemplazar una forma antigua de hacer las cosas con una nueva forma de hacer las cosas. Crear un nuevo componente, extraer un nuevo componente, desaprobar un componente, desaprobar un sistema, lo que sea, puedes tener eso documentado en algún lugar. Algunos equipos prefieren el backlog. Nos dimos cuenta de que los backlogs no son los escenarios ideales para esto porque los elementos tienden a deteriorarse en el backlog, especialmente si los pones en baja prioridad. Así que terminamos con un documento separado, por ejemplo, y animo a todos a hacer esto, tratar de averiguar, okay, cuáles son los aspectos clave de mi base de código que tienen esa creciente deuda técnica. Pueden ser cosas muy pequeñas, o pueden ser cosas más grandes. En este caso, comenzamos a documentar incluso las cosas más pequeñas en este documento llamado contabilidad de deuda técnica. Cada vez que introduces alguna deuda técnica o de repente encuentras algo que, de repente, te das cuenta, hey, esto es deuda técnica que no hemos resuelto, lo documentas en algún lugar. Y no solo está en la cabeza de alguien, hey, hay algún documento técnico allí. En realidad, está documentado en un lugar. Y una vez que llegas a eso, comienzas a establecer prioridades. Y esto es en realidad como una historia divertida. Este es código de producción que todavía tenemos. Tuvimos este viernes en el que implementamos algo llamado vista previa de Markdown, básicamente tomando archivos de Markdown y mostrándolos de manera agradable, formateándolos para la vista previa cuando navegas en la base de código. Y lo tomamos como una especie de, fue casi como una experiencia de hackathon donde simplemente dijimos, okay, construyamos esto.

3. Priorización y Planificación para la Deuda Técnica

Short description:

Tuvimos una idea y la construimos rápidamente, aunque el código estaba desordenado. El componente que creamos no era central para la aplicación, por lo que pudimos priorizarlo en consecuencia. La planificación para abordar la deuda técnica es crucial y se puede hacer a través de la documentación y expectativas claras. El proceso de abordar la deuda técnica es similar al proceso de desarrollar una funcionalidad, con consideraciones de ejecución, responsabilidad y tiempo.

Tenemos esta idea, vamos a construirla. Y la lanzamos en un par de horas, un par de ingenieros. Y, por supuesto, el código es horrible y es solo una larga lista de devoluciones de llamada y complementos sobre complementos y todo tipo de configuraciones rápidas extrañas, pero simplemente funciona.

Y esta parte particular de la aplicación, es un componente en particular, pero está en el borde mismo de la architecture, ¿verdad? No es algo que las personas abrirán a diario y tendrán que navegar. No es una experiencia central, ¿verdad? Incluso puedes desactivarlo si es necesario o es muy fácil, simplemente sacar ese componente de eso y de repente los archivos de Markdown ya no tienen la opción de vista previa.

Entonces, comenzamos, cuando comienzas a pensar en las prioridades, debes entender, okay, no hay forma de que pueda abordar todos los problemas en esta base de código. Así que vamos a priorizar las cosas. ¿Es esto importante? ¿Es esto algo que, es este un componente, es este un sistema o un módulo al que las personas acceden a diario y con el que tienen que lidiar a diario, entonces sí, pongámoslo con alta prioridad y ocupémonos de ello lo más rápido posible. Si no, bien puede ser una cosa de baja prioridad o incluso se puede ignorar. Incluso puede no estar en nuestro radar. No deberíamos centrarnos en esto en nuestro proceso futuro del que hablaremos en unos minutos.

Y finalmente, hablando también del inventario, también puedes agregar aquí planes, ¿verdad? Planificación de qué hacer a continuación. Como, okay, tenemos... No solo hemos descubierto deuda técnica, también la hemos documentado y la hemos priorizado. Pero también podemos decir, okay, para esta deuda técnica en particular, la solución es hacer lo que sea, reemplazar el componente antiguo, el componente heredado con el nuevo componente. Desaprobar este caso de uso, extraer nuevos subsistemas o subcomponentes de eso. La planificación de esta manera se puede hacer, no sé, a través de RFC o cualquier tipo de documento que explique estos son los pasos que debemos seguir para pasar de A a B, ¿verdad?

Porque volviendo a estos dos primeros pilares de los que hablamos, puedes imaginar bastante bien que tus prácticas son como la meta. Creo que ya lo mencioné, ¿verdad? Este es el objetivo que tienes. Aquí es donde necesitamos llegar. Esto es lo que establece las expectativas de todo el equipo de que aquí llegaremos con la base de código. Y el inventario es como darte la dura realidad, por así decirlo, ¿verdad? Aquí es donde estamos ahora. Estamos tan lejos de nuestras prácticas ideales. Entonces, con la planificación y con todos los pasos dados, ¿verdad? Con documentos en ambos lados, con expectativas claras y comprensión clara y todo compartido dentro del equipo de que esto es, ya sabes, esto es cómo procedemos con esto.

Luego, el proceso es el tercer pilar del que hablaremos en un segundo y es como el paso de llevar todo del estado actual al siguiente estado, ¿verdad? Como casi de A a B. Y por eso el plan también es parte del inventario porque te dará los primeros pasos, por así decirlo. Sí, para abordar esta deuda técnica en particular, necesitamos hacer esto, para, ya sabes, pasar del sistema heredado al nuevo sistema, necesitamos abordar esto y aquello. Entonces, es muy importante si tienes estos dos pasos previos, ¿verdad? Si has investigado, si has documentado las cosas, y si el equipo está de acuerdo en cómo avanzar, entonces el proceso se parece mucho al proceso de cualquier funcionalidad de web development, ¿verdad? O cualquier funcionalidad del producto, en realidad. Como, tienes ejecución, ¿verdad? Tienes responsabilidad, alguien se asigna a una tarea en particular. Vale, necesitan cambiar algo, necesitan arreglar una área específica del código. El tiempo también se tiene en cuenta porque hemos priorizado las cosas, hemos planeado soluciones.

4. Pasos para una Refactorización Exitosa

Short description:

Mitigar la deuda técnica requiere seguir tres pasos clave: establecer prácticas, mantener un inventario e implementar un proceso. Sin estos, los esfuerzos de refactorización se vuelven inestables y disruptivos para el desarrollo del producto. Las prácticas proporcionan pautas y objetivos, mientras que un inventario ayuda a identificar áreas de mejora. El proceso garantiza que la refactorización se realice teniendo en cuenta el tiempo y la responsabilidad del equipo. Dos reglas para una refactorización exitosa son hacer las tareas visibles y crear una experiencia gratificante.

Entonces sabemos, okay, mitigar esta deuda técnica en particular que puede llevar una semana, puede llevar una hora, puede llevar más tiempo. Depende, por supuesto, de su complejidad. Y también tienes el progreso, ¿verdad? Cada semana, desde que has planeado las cosas, desde que trabajas con un objetivo claro en mente, también puedes darte cuenta bastante bien de que este es el progreso, estoy a medio camino, ¿verdad? Todavía necesitamos tiempo, o casi he terminado. Entonces, este proceso es algo así como muy similar a cualquier otra funcionalidad. Puede ser una característica del producto, puede ser una característica de ingeniería, o como una tarea de ingeniería como esta. Puedes verlos a través del mismo tipo de lente aquí.

Entonces, solo para recapitular, tenemos las prácticas en un extremo, tenemos el inventario, que nos da la brecha de cuán lejos estamos de este escenario ideal al que queremos llegar, y luego tienes el proceso, que te lleva de A a B. Y es muy difícil hacer un esfuerzo de refactorización estable o constante que no interrumpa el desarrollo del producto si realmente no sigues la mayoría de estas cosas, ¿verdad? Solo piénsalo, si no tienes las prácticas en su lugar, realmente no sabes a dónde vas, como si estuvieras refactorizando en vano, como, okay, estoy refactorizando por el bien de hacerlo. Sabes, solo sé que esto no está bien, pero realmente no sé dónde parar. ¿Cuándo es suficiente, verdad? ¿Cuándo es suficientemente bueno la calidad de ese código o de esa architecture para mí? Si no tienes el inventario, entonces realmente no sabes qué abordar. Comienzas a refactorizar partes de tu aplicación. Y nuevamente, el inventario es súper importante porque a menudo los equipos lo pasan por alto. Y terminas con alguien tomando una tarea, queriendo refactorizar algo, recorriendo todo el código, pero sin tener en cuenta partes del código que ni siquiera se documentaron. Oye, hay algunos problemas allí. También debemos abordar eso. Eso también es legado, no solo, ya sabes, el camino principal que se refactorizó. Y luego, por supuesto, sin el proceso, realmente no puedes tener nada si no tienes en cuenta, ya sabes, el tiempo y el hecho de que el equipo necesita apropiarse de esto y demás.

Entonces, considerando estos pasos, intentemos en la última parte de esta charla, voy a intentar darte un par de ejemplos de lo que llamo las reglas para que esto funcione, ¿verdad? Cosas que noté, después de pensar en este tipo de proceso, como podría funcionar, empecé a ver, okay, ¿cuáles son las cosas que, ya sabes, los equipos están haciendo bien, o los equipos en los que trabajé estaban haciendo bien? Eso ayudó a que este proceso avanzara, ayudó a mantener estas cosas a largo plazo, como si esto se convirtiera en algo más como una cultura, más como una cultura de ingeniería en lugar de ser solo otra cosa en la lista de alguien.

Entonces, la regla número uno es hacer que estas cosas sean visibles, ¿verdad? No puedes realmente refactorizar a oscuras. Existe esta idea errónea común de que, ya sabes, las personas deberían refactorizar cosas por su cuenta, ¿verdad? Cada vez que encuentren algo, simplemente refactorizarlo rápidamente sin que el PM lo sepa porque el enfoque está estrictamente en el desarrollo del producto. Debes ser muy transparente al respecto, y creo que todo debería estar a la vista, ¿verdad? Debería haber tareas claras para la refactorización que se tengan en cuenta cuando se planifica el ciclo cuando se planifica la iteración, cuando se tiene en cuenta la cantidad de tiempo que las personas dedicarán al proyecto, etc. No hay nada de malo en tener eso aquí en tu herramienta de gestión de proyectos en este caso. Así es como lo hacemos en Code Sandbox. También tenemos PRs que están claramente definidos como PRs de refactorización, ¿verdad? No simplemente agregamos algún PR, algún trabajo de refactorización en un PR de una funcionalidad porque entonces, por supuesto, corres el riesgo de arruinar las cosas y retrasar la propia funcionalidad. Así que tratamos de separar. Cada vez que encontramos deuda técnica incluso si es de alta prioridad necesitamos refactorizarlo de inmediato. No lo hacemos en ese PR, simplemente abrimos otro como un PR de seguimiento y abordamos ese problema. Y está claramente marcado como un PR para refactorización porque luego se revisa de manera diferente, ¿verdad? Con diferentes ojos tienes diferentes enfoques para ver el código que se refactoriza en lugar del código que simplemente agrega algo o soluciona algo que, ya sabes, tiene más valor para el producto que para la base de código. La segunda regla es hacer que sea gratificante. Ahora es muy importante que las personas sientan el éxito de la refactorización y de lidiar con la deuda técnica de la misma manera que lo hacen al lanzar algo, ¿verdad? Obtienes, cuando trabajas en un equipo de producto cuando lanzas algo, obtienes una nueva versión obtienes esa, ya sabes, esa buena vibra de, hey, lanzamos esto, lo logramos, es una historia de éxito.

5. Celebrando el Éxito y Garantizando la Resiliencia

Short description:

En Code Sandbox, celebramos el éxito deshaciéndonos de código innecesario y abordando preocupaciones comunes. Realizamos sesiones regulares para eliminar componentes no utilizados y limpiar la base de código. Es importante priorizar el desarrollo del producto, pero también hacer un seguimiento de la deuda técnica y continuar documentando y discutiendo futuras refactorizaciones. Todo el equipo debe participar y asumir la responsabilidad para que el proceso sea resiliente.

Entonces, lo que hacemos en Code Sandbox, también celebramos, ya sabes, cualquier tipo de éxito, que incluso puede ser como, okay, nos deshicimos de un montón de código el viernes. Esto es algo que recientemente, recientemente comencé. Siempre tienes en nuestro canal de Slack, siempre, ya sabes, en diferentes bases de código, la gente está diciendo, oye, acabo de refactorizar todo esto. Se sintió muy bien. Nos deshicimos de un montón de cosas. Abordamos algunas preocupaciones comunes que teníamos en el pasado y ahora todo ha desaparecido y es perfecto. Y tratamos de celebrarlo junto con el equipo y lo vemos como un éxito.

Otra forma de celebrar, y en realidad algo divertido que hacemos desde finales del año pasado, es tratar de deshacernos básicamente de código que no nos genera alegría. Y llamamos a esto la Marie Kondo de la base de código. Así que nos reunimos en nuestra oficina virtual una vez cada viernes aproximadamente. Y decimos, oye, necesitamos manejar estas partes particulares, tenemos algún código que existe desde hace tiempo y realmente no aporta mucho valor. Podemos eliminarlo. Incluso si es una pequeña función que tal vez se olvidó en algún lugar. Si sabemos que ya no se utiliza, simplemente lo eliminamos. Si hay componentes que no se utilizan, si hay componentes que no están al mismo nivel que otros componentes en el sistema de diseño, tratamos de nivelarlos y lo que sea que sintamos que es como esa picazón, sí, esto necesita desaparecer. Necesitamos una mejor manera de hacer esto o simplemente tenemos que eliminarlo. Luego lo hacemos en estas sesiones. Terminamos documentando todo esto nuevamente y llevando un registro. Y cada mes tratamos de dedicar tiempo y simplemente hacer esta limpieza. Simplemente sacar esto del sistema, sacar esto de la base de código y mantener la deuda técnica y todas estas cosas heredadas al mínimo.

La última regla es un poco difícil, es hacer que sea resiliente, porque la mayor amenaza para esto, para una cultura exitosa de refactorización, es una cultura en la que el desarrollo de funciones y el desarrollo del producto siempre tienen prioridad. Y no me malinterpretes, el desarrollo del producto siempre tendrá mayor prioridad y está bien porque eso es lo que debes hacer al final del día, esa es la tarea principal. Simplemente que cuando las cosas se vuelven muy intensas, cuando no tienes tiempo para hacer todas estas cosas, aún debes asegurarte de que todo el proceso sea resiliente. Al menos asegúrate de que, okay, este mes no tendremos tiempo para hacer ninguna refactorización, pero seguimos haciendo un seguimiento de la deuda técnica. Seguimos documentando cosas. Seguimos discutiendo sobre las prioridades, sobre la refactorización futura. No dejamos que esto se deslice porque es muy fácil que el proceso simplemente se vaya, okay, no nos ocupamos de esto ahora y lo retomaremos en cualquier momento. Y ese momento puede ser en cualquier momento en el futuro. Pero lo importante aquí es hacer que sea resiliente, tienes que tener la compra de todo el equipo. Y no solo la compra, sino también la responsabilidad de todo el equipo.

6. Construyendo una Cultura de Refactorización Resiliente

Short description:

Para hacer que nuestro proceso sea resiliente, tenemos reuniones regulares para abordar problemas en la base de código y documentar nuevas tareas. Cuando se da prioridad a algo, asignamos una propiedad clara y tomamos medidas concretas. Cada miembro del equipo puede impulsar la cultura de refactorización y adoptarla como un modelo de propiedad compartida. ¡Gracias y feliz refactorización!

Lo que hacemos aquí para hacerlo resiliente es tratar de mantenerlo bajo control. Siempre que pasamos por un período de desarrollo de nuevas funciones, seguimos teniendo estas reuniones y también tenemos estas reuniones de equipo con todo el equipo horizontal, incluso si trabajamos en diferentes equipos de producto. Nos reunimos y decimos, oye, en esta base de código todavía tenemos este problema. No hemos tenido tiempo de hacer nada al respecto pero este es el plan. Lo estamos impulsando. Hemos documentado cosas nuevas. Tratamos de mantenerlo bajo control. Tratamos de que todos en el equipo sean conscientes de que este proceso aún está ahí aunque tenga baja prioridad por el momento.

Y por supuesto, cuando tienes prioridad para eso, haz que estas reuniones sean más concretas. Asigna una propiedad clara. X puede encargarse de actualizar algunas pruebas antiguas. Y puede agregar nuevos componentes al sistema de diseño, estandarizarlos porque los usamos en varios lugares. Hay un montón de ejemplos como estos de cosas concretas que puedes hacer de forma semanal. Estas fueron más o menos las reglas y este es el proceso que tengo en mente y el marco que tengo en mente para construir esta cultura de refactorización.

Quiero dejarles con una cita que adapté y es que, cada equipo tiene una persona que impulsa esta cultura de refactorización y si no sabes quién es, probablemente seas tú. Quiero animar a todos a llenar este vacío si sientes que no hay nadie, ya sabes, impulsando este esfuerzo, se necesita un poco de esfuerzo para ser el impulsor, pero estoy bastante seguro de que usando estas cosas, usando este modelo de propiedad compartida, puedes convencer a todos en el equipo de que este es el enfoque correcto y luego el equipo puede comenzar a adoptar esto como una cultura, no solo como algo que una sola persona impulsa. Muchas gracias y feliz refactorización. Y estoy muy contento de ver a Marie Kondo nuevamente en acción y de que no la saquen del escenario o de los escritorios. Veo que están caminando por la oficina. ¿Cómo estás hoy? Estoy bien, gracias. Y muchas gracias por tenerme aquí. Vamos a pasar a la diapositiva, la pregunta que preparaste para nosotros y ver los resultados. ¿Cómo te sientes al respecto? Algunos, bueno, el 46% de las personas dijo que tienen asignado más del 20% del tiempo y el 37% entre el 10 y el 20% del tiempo. Por supuesto, parece que fluctúan un poco. Aún no, pero la tendencia está ahí. Es bastante interesante. No realmente. Creo que en general, es un resultado positivo. Diría que el hecho de que las personas asignen tiempo para esto es un indicador muy bueno de que la industria se está inclinando hacia un software más sostenible, todo se siente un poco más organizado. Parece que hemos avanzado desde ese período en el que los gerentes decían que no era necesario escribir pruebas.

7. Importancia de la Visibilidad y el Apoyo

Short description:

Es importante reconocer la necesidad de más tiempo para mantener las cosas bajo control y garantizar un crecimiento constante. Herramientas como formateadores, linters y tuberías de CI pueden ayudar a mantener la calidad del código, pero también son necesarios procesos manuales. Convencer a los gerentes de producto se puede hacer con métricas, gráficos y demostrando el impacto en la experiencia del desarrollador. La propiedad y las preocupaciones comunes dentro del equipo son cruciales. Los riesgos y el impacto en el producto deben comunicarse para obtener visibilidad y apoyo.

Simplemente haces un trabajo lo suficientemente bueno y luego el código se prueba a sí mismo y cosas así. Creo que es un indicador positivo de que las personas reconocen que necesitan más tiempo para mantener las cosas bajo control y asegurarse de que el proyecto basado en código y una pieza de tecnología crezcan de manera constante.

Sí, hay esperanza de que no solo enviar código sea el camino a seguir. También cuidar el resto y cómo se integra es un papel importante.

También tenemos algunas preguntas de la audiencia y voy a responder a ellas. Y la primera sería, ¿qué herramienta estás usando para llevar a cabo este proceso o herramientas, si hay más? Entonces, sí, es una buena pregunta. Supongo que si se trata específicamente, de herramientas específicas que te ayuden en estos procesos, desafortunadamente, es un proceso bastante centrado en el humano porque en mi opinión, bueno, si tienes herramientas, por ejemplo, para cosas de las que hablé, como mantener un cierto nivel de calidad del código de las directrices de codificación. Si hay cosas que se pueden automatizar entonces ni siquiera vale la pena mencionar el proceso. Simplemente tienes todos los formateadores, tienes linters, tienes tuberías de CI que validan todo y mantienen las cosas bajo control.

Para todo lo que no se puede automatizar, significa que tampoco hay realmente una herramienta que pueda resaltar las cosas. Puedes comenzar a mirar cosas como la complejidad del código, pero diría que siempre tomes eso con precaución, asegúrate de que no sea como, no solo puedes tener herramientas que te ayuden, pero nunca puedes confiar al 100% en las herramientas si hay cosas que no se pueden automatizar por completo. Por ejemplo, confiamos en cosas como el `node prune` que es un paquete que se puede ejecutar en bases de código más grandes para darte paquetes y módulos que no se utilizan, que a veces algunas de esas cosas no se detectan fácilmente. Entonces, hay algunas soluciones disponibles, pero desafortunadamente diría que la gran mayoría de los procesos de los que hablé son un poco manuales y requieren cierto grado de propiedad humana, por así decirlo.

De hecho, de hecho. Y ahora que mencionaste la perspicacia humana, Marie Kondo recibió aprecio. Ah, genial. La gente dijo que les encantó que lo llamaras el método Marie Kondo, pero parece que esta persona no tiene necesariamente problemas para convencer al lado comercial de que necesitan abordar la deuda técnica. Pero en general, ¿cuál sería tu enfoque para convencer al gerente de producto, al propietario del producto de que se debe considerar más la deuda técnica y que no se debe simplemente pasar por alto?

Bueno, creo que la respuesta clásica para eso es, ya sabes, siempre, si necesitas, como si no tienes, ya sabes, la propiedad sobre eso, si necesitas convencer a alguien, probablemente los convencerás con algún tipo de números, gráficos, como la idea de que, oye, sabes, hace seis meses o un año estábamos enviando funciones a este ritmo, ahora estamos enviando a este ritmo, y como, esta es una diferencia. Y esto es, ya sabes, claramente tenemos un problema, ya sabes, la experiencia del desarrollador se ha ralentizado o cosas así.

Sí, creo que personalmente tengo la suerte de haber trabajado en los últimos años en un entorno donde creo que todos están de acuerdo en esto, así que se trata más de la propiedad. Como más, la mayoría, se trata más de nosotros asumir la responsabilidad de hacer el proceso en lugar de tener que pedir permiso para hacerlo o algo así. Pero sí, siempre hay, creo que siempre hay métricas que se pueden obtener sobre qué tan rápido la gente está entregando. También puedes tener simplemente la, tener la sensación de cómo se siente el equipo acerca de las cosas. Si estás en una posición para hacerlo, ten una reunión individual con cada ingeniero del equipo y haz que las preocupaciones comunes sean expresadas por todos. Así queda claro que hay un frente común que el equipo tiene contra este problema que está creciendo.

Sí, István, lo que estaba diciendo es que quería mencionar que a veces también es mencionar los riesgos y ponerte en la situación de que el propietario del producto, la persona del producto verá que algo está saliendo mal debido a esto. Y literalmente acabamos de recibir la pregunta ahora mismo ya que está muy relacionada con eso. ¿No es irrelevante para el producto que algunas de las tareas de refactorización puedan llevar mucho tiempo en comparación con el desarrollo de funciones, lo que significa que mencionamos que podemos decidir y asignar este tiempo, pero para el producto podrían simplemente descartarlo. ¿Por qué debería ser distinto y visible para los equipos de producto?

Cuando me refiero a los equipos de producto, me refiero a que debe ser visible para todos los que están preocupados por ellos. No es como, ya sabes, algún ingeniero en la sombra hace la refactorización y otros solo lo prueban.

8. Comunicación Transparente y Disponibilidad

Short description:

Al final, es importante ser transparente acerca de las responsabilidades del equipo. Escribir pruebas y tareas no relacionadas con la codificación también forman parte del trabajo. El estilo de operación del equipo puede no ser completamente visible para el gerente de producto, pero deben estar conscientes de ello. La disponibilidad puede dividirse entre diferentes tareas. ¡Gracias por unirse a nosotros hoy!

Al final, dicen, hey, envíalo allí. Simplemente cubrámoslo en algún lugar. Se trata más de ser transparentes y que es solo parte del trabajo. De la misma manera que, ya sabes, escribir pruebas es parte del trabajo o cualquier otra tarea no relacionada con la codificación de alguna manera es parte del trabajo de la misma manera, diría yo.

Por lo tanto, no necesariamente tiene que ser visible para el gerente de producto o el propietario del producto o completamente transparente para ellos, pero deben estar conscientes de cómo opera el equipo. Y también ser transparentes con la disponibilidad de uno mismo. Estas pocas horas se invertirán aquí. No es que no estén haciendo trabajo de producto en vano. Es que mi disponibilidad se dividirá entre esto.

Realmente, realmente interesante charla Alex. Y estoy muy contento de que hayas compartido todas las ideas y los procesos que has establecido con este marco de trabajo. Muchas gracias por unirte a nosotros hoy. Gracias. Gracias por invitarme. Adiós. Adiós. Gracias. Gracias por invitarme. Adiós. Gracias por invitarme. Adiós. Gracias por invitarme. Adiós. Gracias por invitarme. Adiós. Gracias por invitarme. Adiós. Gracias por invitarme. Adiós.

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 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 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.
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.