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

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 ciudad tan genial. Ya he estado aquí antes. Estuve en esta conferencia en 2018. Lo pasé muy bien.

Oh, sí. Entonces, comencemos. Entonces, 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 mencioné, estoy organizando JS Heroes. Este es un evento de community con sede en Cluj, Rumania. Nuestro próximo evento es en mayo de 2023. Así que espero ver a algunos de ustedes allí también. Ven a buscarme después de la charla. Podemos hablar más si estás interesado en esto.

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

Por qué quiero hablar sobre la refactorización o por qué esta charla es sobre la refactorización. Quiero hablar sobre la cultura de la refactorización. No estoy aquí para decirte formas de refactorizar code o técnicas para mejorar tu code o mejorar tus React componentes o frontend en general. Me fascina principalmente por qué no hemos descubierto cómo refactorizar nuestro code, nuestras bases de code sin realmente impactar el desarrollo del producto.

He trabajado con tantos equipos diferentes en los últimos años y especialmente con equipos de producto. Siempre ha habido este problema de, está bien, hemos acumulado deuda técnica, ahora es el momento para hacer la refactorización. Entonces, ya sabes, gerentes de proyectos, por favor hagan a un lado. Es el momento para que los ingenieros tomen el escenario y trabajen durante un mes reescribiendo todo, introduciendo un nuevo framework o lo que sea solo 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 alrededor de la introducción de la refactorización y tratarla como cualquier otra tarea en un proyecto.

Y esto se volvió aún más claro para mí hace unos meses cuando introdujimos esta nueva cosa en la base de code sandbox code. Entonces, tenemos esta cosa llamada un 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 data desde la VM. Y presentamos una nueva forma de consumir los data de pitcher. Entonces ahora lo que tenemos es un proveedor de pitcher legado y un proveedor de pitcher, ¿verdad? Y eso está perfectamente bien. Nunca dijimos, está bien, ahora tenemos que detener todo en code sandbox y tenemos que centrarnos en deshacernos de la forma antigua porque tenemos una nueva forma de consumir data. Y creo que esto es realmente valioso. Entender que está bien vivir con deuda técnica. No tienes que sentirlo necesariamente como una carga. Pero sí tienes que gestionarlo. Entonces, 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á mal. Tal vez ni siquiera debería ser luchando contra la deuda técnica sino más bien gestionando la deuda técnica. Entonces, lo que voy a mostrarte en los próximos minutos es un framework de cómo yo creo que podemos gestionar la deuda técnica en los equipos de ingeniería. Y lo llamo los tres pilares de la refactorización. Porque, bueno, obviamente tiene tres pilares. Uno es prácticas, uno es inventario, y uno es el proceso. Y los voy a tomar uno por uno y explicar qué quiero decir con ellos. Entonces, primero, tenemos prácticas.

Este es tu objetivo. Por así decirlo, desde la perspectiva de la ingeniería. Quieres alcanzar una cierta architecture. Quieres tener una cierta forma de componer tus componentes. Quieres tener una forma de consumir un sistema de design, digamos.

Así que aquí tienes todos tus patterns y tu architecture. Puedes dibujar tus diagramas, documentas cómo trabaja el equipo de ingeniería, cómo piensan a muy alto nivel sobre hacia dónde quieren que vaya la base de código. Pero también luego profundizas, bajas y bajas en términos de abstracción.

Así que puedes tener en tus prácticas, ¿cómo estructuras normalmente el code? ¿Creas carpetas para cada componente? ¿Divides los archivos por función? ¿Divides los archivos por característica? ¿Cómo estructuras simplemente tu code en general? E incluso más abajo a nivel de code, puedes tener tus directrices de codificación. Y no estoy pensando necesariamente aquí en cosas que pueden ser automatizadas, sino simplemente en patterns que tú y tu equipo descubren, oye, hay tres formas, y tal como mostró Nick, hay tres formas de hacer algo. Especialmente con React. Escojamos una. Documentemos nuestra forma de trabajar. Usamos Code Sandbox, estas son las directrices generales de codificación que tenemos internamente y a las que hacemos referencia en todos los PRs.

Así que siempre que hay una discussion en un PR, como ¿deberías componer componentes así o así? Oh, sí, en realidad, hay una directriz para eso. Si no hay una directriz para eso, ahora es un buen momento para, ya sabes, añadirla allí. Así que estas son prácticas, ¿verdad? Esto es el... Como esto te está dando la Estrella del Norte de lo que quieres lograr con tu proceso de refactorización. Y ahora pasamos al inventario, que puede ser el más importante y puede ser el más pasado por alto.

Y en mis experiencias pasadas con diferentes equipos, noté que mucha gente trata esto de manera bastante superficial. Así que el inventario es acerca de recopilar todos los hechos. ¿Qué sucede en la base de código? ¿Ahora qué tan lejos estamos del resultado deseado, verdad? Así que esto es acerca de registrar cosas, digamos, en el backlog. Eso es una cosa que probablemente es la 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 de backlog en code sandbox es que tienden a simplemente pudrirse allí en el backlog porque nadie los revisa. Así que empezamos una nueva cosa llamada la contabilidad de deuda técnica, que es un documento separado al que hacemos referencia, de nuevo, en los PRs. Siempre que un PR, digamos, introduce una deuda técnica por diferentes razones, como no falta de tiempo o simplemente aún no tenemos la abstracción para algo, decimos, OK, pongamos esto en el documento de contabilidad de deuda técnica. Expliquémoslo allí. ¿Por qué introdujimos la deuda técnica? ¿Cuál es una posible solución para ello? ¿Quién la posee? ¿Quién no es necesariamente quien la resolverá, sino más bien quien levantará la bandera de que, oye, sabes, esto es importante y aún no lo hemos resuelto? Y luego, finalmente, le asignamos una prioridad. Y esto también es parte del proceso de inventario.

Asignación de prioridad. Porque no toda la deuda técnica es igual de alguna manera. Y en realidad 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 markdown, en lugar de ver el code markdown, también puedes ver la vista previa de cómo se ve ese markdown.

Así que tomamos tres o cuatro horas más o menos, pusimos allí un montón de dependencias, bibliotecas que hacen todo el trabajo. Simplemente conectamos cosas. Añadimos algunos plugins. Así que tiene alguna funcionalidad personalizada. Como, ya sabes, puede seguir rutas, abrir archivos y cosas así. Pero nunca nos molestamos en refactorizar esto. ¿Por qué? Porque este archivo no ha sido tocado desde entonces. Simplemente funciona, ¿verdad? Entonces, si funciona, ¿por qué necesitarías tocarlo? Porque este archivo vive en la extremidad de la base de código. No es algo que los desarrolladores abran diariamente y tengan que luchar con él y pasar por él y entender qué está pasando 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 tienes tus prioridades claras, puedes empezar a planificar un poco. También, parte del paso de inventario. Es muy importante decir, vale, y especialmente para las cosas más complejas. No estoy diciendo aquí que debas planificar para cuando quieras renombrar algo o cuando quieras limpiar algo de code. Pero más bien, para las deudas técnicas más importantes que son realmente complicadas y quizás son de varios meses de duración, puedes tener algo como RFCs o cualquier tipo de documentation que te permita planificar con anticipación y compartir con todos para que todos tengan un entendimiento 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. Realmente no importa. Vamos a intentar seguir con ello, pero no vamos a detener ningún otro proceso.

Esto no nos va a bloquear porque tenemos el plan para mitigar esta deuda. Así que para recapitular estos dos primeros pilares de los que hemos hablado, es casi como dije, las prácticas son tu objetivo. Así que dices, vale, esto es a donde queremos llegar eventualmente. Y luego con el inventario, dices, oh sí, estamos alrededor de aquí ahora. Estamos tan lejos de esta buena idea, buena solución o buena arquitectura a la que queremos llegar. Y no estoy diciendo perfecto porque no deberías necesariamente apuntar a la perfección aquí. Y luego el inventario te dará este tipo de brecha, te mostrará, oh sí, estás tan lejos de tu objetivo. Así que ahora es el momento de aplicar el proceso y refactorizar cosas y simplemente tomar el tiempo, planificar con anticipación y manejar todos estos cambios. Así que 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 gestores de proyectos harán, o los analistas de negocio harán el análisis del producto de antemano y dirán, vale, tenemos que entregar esta característica, va a tener este impacto o va a 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 de antemano, entonces simplemente haces prácticamente todo lo que haces en una tarea regular. Tienes la ejecución, tienes cierta propiedad, alguien se asigna a algunas tareas, toma algún tiempo, tiene algunas estimaciones, tienes algún progreso, tienes una definición de hecho, ¿cuándo se va a terminar esta tarea? Así que aquí está una visión general de todo, sólo como un rápido resumen, mientras quizás tomo un sorbo de agua aquí. También encontré esto muy importante para tratar de visualizarlos tal como son. Y también, quizás una cosa que me perdí aquí, es muy difícil hacer la refactorización de una 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 tengas ingenieros refactorizando simplemente porque les gustan ciertos patrones, pero no es el terreno común que el equipo apunta. No es algo en lo que te hayas asentado. Si no tienes el inventario, puedes tener las prácticas. Sabes que quieres llegar allí, pero no tienes idea de cuál es tu deuda técnica. ¿qué estás resolviendo realmente o tal vez estás refactorizando en vano? Por supuesto, no puedes hacerlo sin el proceso real, que es hacer los cambios reales que quieres hacer. Correcto. Hemos pasado por esto. Ahora, en la segunda parte de la charla, quiero darte un par de ejemplos de cosas que estamos haciendo ahora con el equipo de ingeniería en code sandbox. Los llamo reglas para hacer que esto funcione. Porque estoy seguro de que estás pensando que esto es muy teórico y quizás no se aplica a mi proyecto o a mi contexto. Pero creo que con un par de ejemplos de cosas que los equipos pueden hacer, creo que se hará un poco más claro. Y los llamo reglas para hacer que funcione, porque parece que necesitas ciertas reglas para guiarte a través de todo el proceso. Y la primera es hacerlo visible.

Un gran problema que tengo con la refactorización en general es que existe esta preconcepción de que la refactorización debería hacerse en la oscuridad. Los ingenieros simplemente deslizan algunos commits al final de un PR solo para mejorar algo de code. Y eso solía ser una buena práctica. Pero realmente creo que en un equipo más metódico donde realmente quieres apegarte a un plan, necesitas hacer todas estas cosas visibles. Así que sí.

Ten tickets claramente separados en tu herramienta de gestión de proyectos que digas, quiero... Durante este ciclo, durante este sprint, cualquier proceso que estés utilizando, vamos a manejar estas cosas que son ya sea deuda técnica, refactorización o lo que sea. Haz PRs separados para la refactorización también. Como, si pones cambios en tus PRs de producto que son refactorización del code, primero que nada estás haciendo más lento integrar nuevas características porque ahora la revisión del code puede ser el doble de complicada porque tienes más cambios en el PR. Pero también, si lo piensas, deberías estar mirando de manera diferente a un PR que maneja cambios de producto versus un PR que maneja la refactorización. Debería ser un objetivo diferente y el nivel de la revisión debería ser ligeramente diferente.

La segunda regla es hacerlo gratificante para el equipo. Necesitas tener la aprobación de todos en el equipo de ingeniería. Lo que significa que necesitas asegurarte de que es fácil contribuir a cualquier esfuerzo de refactorización. También es gratificante. También es celebrado. La refactorización puede ser bastante desalentadora, 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 celebrar. Cada vez que eliminamos code, decimos, sí, hicimos esto. Y todo el equipo celebra. prácticamente la misma sensación que si acabas de enviar una característica importante, porque enviaste algo en tu hoja de ruta, enviaste 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 recientemente empezamos es deshacernos del code que no produce alegría. Y tenemos esto ahora, de vez en cuando, llamamos a la Marie Kondo de la base de code donde nos reunimos con el equipo de ingeniería un viernes en nuestra oficina virtual y empezamos a desmontar cosas del code, cosas que no necesitamos o simplemente cosas que en general pueden ser reescritas. Nos tomamos el tiempo y realmente celebramos esto. Incluso lo tenemos ahora muy formal que reunimos todas estas ideas mensualmente y decimos, oh, para el próximo mes, vamos a ocuparnos de estas cosas. Tal vez cosas surgen durante el mes y decimos, sí, simplemente lo haremos durante el viernes de Marie Kondo. Así que se convirtió en algo desde hace un par de meses. La última cosa es hacerlo resistente. Así que no solo necesitas hacerlo visible, necesitas hacerlo gratificante, pero necesitas ser consciente de que esto al final del día no es la entrega del producto. La entrega del producto probablemente tendrá una prioridad más alta y probablemente tiende a sacar otras cosas del camino, ¿verdad? Así que cuando eso sucede, cuando te enfrentas a un plazo ajustado y todo, necesitas asegurarte de que el proceso es resistente.

Incluso si está en baja prioridad, incluso si es de bajo esfuerzo, sigue ahí, ¿verdad? No pierdes la pista de ello. No dejas que la deuda técnica abrume todo el asunto.

Lo que hacemos es que tenemos estas reuniones de ingeniería semanales 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 discussion sobre la entrega. No hay discussion sobre las liberaciones. Solo hablamos sobre la health del code. Solo hablamos de cualquier cosa relacionada con DX que levantamos las banderas, ¿verdad? Si tenemos deuda técnica que no se ha abordado y está en 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 propiedad. Alguien tiene que llevar la bandera. Incluso si estamos pasando por este período difícil en el que necesitamos entregar de manera continua, mantenemos un seguimiento de estos esfuerzos. Incluso si solo está en el fondo de nuestras mentes.

Y como la última pregunta, si tienes personas que simplemente poseen diferentes partes del proceso de refactorización ¿quién posee el proceso más grande? Y creo que idealmente alguien en el equipo debería asumir ese papel. 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 una persona que impulsa la cultura de refactorización... Lo siento, cada equipo tiene una persona. Y si no sabes quién es, probablemente seas tú.

Muchas gracias y feliz refactorización. Muchas gracias. Muchas gracias, Alex. ¿Te sentarías? Una charla tan importante, tan importante. Personalmente me encuentro actualmente bajo mucha deuda técnica, pero mi único consuelo es que yo escribí la deuda técnica, así que solo puedo odiarme a mí mismo. Bueno, creo que la risa significa que probablemente las preguntas ya están arriba, y hay una pregunta realmente buena que creo que necesitamos empezar. Así que mostraste el PR donde eliminaste, ya sabes, miles de líneas de code. ¿Cómo explicas el valor de esto a Elon Musk? Y tal vez más específicamente, creo que la pregunta es... Así que 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.

Pero para la gerencia, la deuda es una palanca. Te ayuda a moverte más rápido, te ayuda a hacer las cosas. Entonces, ¿cómo tienes esta conversación con tu alta gerencia si necesitas hacerlo, donde tu equipo de ingeniería tiene quizás una concepción ligeramente diferente de la que tiene tu gerencia? Sí. Creo que este es un tema delicado porque personalmente... Siento que estoy en una posición privilegiada porque nuestro fundador es técnico, así que él entiende esas cosas, y estoy seguro de que hay equipos en los que es un poco más difícil hacer eso. No sé si simplemente lanzar 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 entenderán si simplemente muestras algunas métricas de productivity, ¿verdad? El equipo es más lento porque tienen que recoger una pieza de code que molesta a todos, ¿verdad? Esos son el tipo de cosas que, por ejemplo, intentamos resolver con los esfuerzos de Marie Kondo, ¿verdad? Oh, hay este molesto componente de router al que tenemos que ir diariamente y tiene algunas importaciones aleatorias y tenemos que resolverlo. O hay este componente de layout muy extraño que renderiza todas las subpartes de la aplicación y siempre nos molesta porque nunca podemos encontrar algo allí. Entonces, como, elegiría una cosa y simplemente mostraría cuán mala es la productivity. Simplemente mostrar, incluso como mostrar una grabación de alguien haciendo un pequeño cambio y lo difícil que es encontrar lo que necesitan cambiar. Sí, ese es un muy buen punto. Y también, creo que a Elon Musk le gustará cuando hagas una gran diferencia porque él simplemente quiere ver mucho code escrito. Sí. Ya sabes. Sí, exactamente. ¿Cómo entendería él el code de todos modos? Entonces. Exactamente. Alimentarlos con mierda y mantenerlos en la oscuridad, ¿no es eso? Ya sabes, cómo lo hacemos. Sí, exactamente. Correcto.

Muy bien. Hay bastantes preguntas sobre la priorización. Y creo que lo abordaste hacia el final. Pero creo que lo que todo el mundo realmente quiere saber es una regla de pulgar sobre cómo priorizas la deuda técnica y cuánto tiempo asignarías a ella? Como en un equipo de ingeniería. Y entiendo que esto va a ser diferente en equipos y diferentes ciclos de vida del producto. Pero, ¿hay un número que podrías, sabes, que cualquiera podría llevar a sus jefes y decir Alex Moldovan de Code Sandbox dijo que deberíamos pasar al menos el 70 por ciento de nuestro tiempo refactorizando. Sí. No querría que la gente me demandara más tarde por darles 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 están haciendo, no se siente como si alguien lo estuviera haciendo de alguna manera. Sabes, como que está distribuido. Así que, no es como, oh, una persona en nuestro equipo de seis está refactorizando a diario y los otros cinco están haciendo solo desarrollo de producto. Es más como que cada uno de los seis ingenieros está trabajando. Y también están entregando cosas del producto. Así que realmente, realmente, es como que, pone al equipo en una posición más favorable. Porque ya no tienes que pensar en que una persona está fuera de la ecuación porque están haciendo el trabajo pesado de refactorizar. Pero sí necesitas tener las cosas de antemano. Como, entiendo que lleva tiempo, por ejemplo, documentar cosas y lleva tiempo incluso crear un ticket, digamos. Así que si tienes el proceso en marcha, es mucho mejor. Si tienes todas las cosas ya de antemano, entonces simplemente señalar otra deuda técnica que se incluyó o simplemente cualquier otra cosa se vuelve más fácil. Como que la barrera de entrada es más baja para contribuir al esfuerzo. Por supuesto.

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

Tenemos un par de preguntas más. Creo que sé que evitaste temas técnicos aquí, pero la pregunta más popular es un poco técnica, si puedo. Sí. Así que la refactorización con PRs es difícil. Pensamientos sobre el desarrollo basado en tronco, el uso de banderas de características, etc. ¿Existen alternativas a tu flujo estándar de PR de GitHub que puedas, ya sabes, hacer para facilitar la refactorización? Puedes pensar ahora en algo en particular. Creo que probablemente se complica más una vez que tienes un proceso de entrega más complicado. Así que si necesitas enviar en una base semanal o cada dos semanas, o estás trabajando hacia una rama de RC, y luego tienes que averiguar, ¿cuándo voy a incluir este trabajo de refactorización en ella? La mayoría de las veces, creo que lo que hice en el pasado, y no es solo con la cosa actual, es simplemente en general cómo trabajo. Las PRs de refactorización estuvieron vivas durante más tiempo. Así que no es como si hiciéramos la refactorización, alguien simplemente la aprobó y la fusionamos inmediatamente, era más como, hey, estamos trabajando en esto. Lo mantenemos durante más tiempo hasta que nos aseguramos de que es el momento adecuado para fusionarlo. Así que tal vez es justo después de un lanzamiento importante cuando hemos terminado con las correcciones de errores o la parte de QA antes del lanzamiento. Así que realmente no afecta la entrega de ello. Así que tal vez esa es la respuesta correcta, la mejor respuesta por ahora. Simplemente ramas de larga vida que... Por supuesto, sé que probablemente es más difícil porque introducen conflictos y cosas así. Pero aún así, es mucho mejor que no tener estas ramas de refactorización en absoluto.

Y creo que eso tiene una pregunta relacionada. Voy a escoger una. ¿Podrías compartir rápidamente tu punto de vista sobre cómo la cobertura de pruebas y la cultura de refactorización están vinculadas? Porque una, obviamente, las pruebas facilitan la refactorización pero también a veces la dificultan porque también estás refactorizando pruebas a medida que avanzas en el núcleo. Cierto. Sí, en realidad tenía una diapositiva sobre eso y la eliminé porque simplemente sentí que no encajaba realmente con las otras cosas. Pero quería en algún momento también hablar sobre cómo hacer todo este proceso seguro. Así que, en mi mente, las pruebas son super importantes, son cruciales para esto porque no tienes la certeza si no tienes las pruebas correctas y digamos la seguridad de tipo. Si no tienes seguridad de tipo, es muy difícil refactorizar cosas, especialmente a medida que la aplicación se hace más grande. Creo que esta fue la primera cosa que me vino a la cabeza como, oh, por qué, TypeScript es tan increíble porque ahora simplemente puedo empezar a cambiar algo y debería propagarse en todos los archivos donde la compilación estaba fallando. Y con las pruebas, creo que es super importante tener una variedad de pruebas para la refactorización. Si solo tienes pruebas unitarias, la mayoría de las veces cuando refactorizas, tendrías que mejorar esas pruebas unitarias también.

Si tienes pruebas de integración y pruebas de extremo a extremo para complementar eso, entonces esas deberían convertirse en tu ancla, ¿verdad? Y te aseguras de que esas siguen funcionando mientras las otras se reescriben. Sí, eso es absolutamente cierto.

Así que tenemos tiempo para una última pregunta. Tenemos en realidad tantas preguntas, así que por favor habla con Alex en la sala de preguntas y respuestas de los ponentes después. Última pregunta, muy rápidamente, refactorización versus reescritura, ¿cuáles son tus pensamientos? Siempre tratando de refactorizar. Reescribir, creo que pasamos por un período de tiempo, justo como Nick estaba mostrando antes, como el período inicial de desarrollo de front-end cuando de alguna manera 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 de front-end. Algunos argumentarían que no, pero yo diría que somos mucho más estables que lo que pasó hace 10 años. Siempre impulsaría la refactorización y la evolución de la architecture, evolucionando la base de code en lugar de una revolución de simplemente tirar todo a la basura y comenzar desde cero. Absolutamente.

Bueno, eso es todo el tiempo que tenemos 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 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.