Un Marco para Gestionar la Deuda Técnica

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 está en el hermoso corazón de Transilvania, donde trabajo como ingeniero frontend en CodeSandbox y, por otro lado, soy también 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 puedes encontrarme en Twitter en alexandmodovan y el tema de hoy es un marco para gestionar la profundidad técnica.

Y quería hablar sobre la profundidad técnica desde hace un tiempo y básicamente esta charla también no es solo sobre la profundidad técnica, que es inevitable para todos los proyectos, para todos los equipos de ingeniería, sino que también se trata de la refactorización. Y no necesariamente voy a hablar contigo sobre cómo refactorizar código o aquí hay algunos patrones para hacer realmente la refactorización. Estoy aquí para hablar un poco más sobre la capa meta, si quieres, y quiero hablar sobre la cultura de la refactorización, porque he estado trabajando durante los últimos cinco a 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 lográramos hacer bien la refactorización. Como industria todavía tenemos este problema mucho.

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 construyes 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 llegó hace unos buenos meses. Cuando estábamos trabajando en Code Samples, estábamos trabajando en esto, 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 imagen, que maneja todos los primitivos de bajo nivel de lo que puedes considerar un editor de código. Como el 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 imágenes heredado, que estaba en la cima de todo. Y luego dentro de él, tenemos algo llamado proveedor de imágenes. Y solo mirando este código al principio, solo mirando el PR que estaba introduciendo este cambio, me hizo gritar, como, oh, no, esto no está bien. Estamos arruinando el código, vamos a vivir con esto para siempre. Y esto es solo una mala práctica. Pero luego lentamente empecé a entender que, en realidad, esto está bien, ¿verdad? En aquel entonces no había forma posible para nosotros de simplemente hacer la transición de toda la base de código de la noche a la mañana, y simplemente usar la nueva forma de consumir datos. Así que tuvimos que soportar estas dos formas alternativas. Y esto es lo que 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, esto está bien, ¿verdad? Esto es más como manejar todo este problema, ahora tenemos esta deuda técnica, somos conscientes de ella, pero la estamos gestionando al mismo tiempo. No estamos, ya sabes, deteniendo todo el desarrollo para centrarnos solo en esto. Estamos avanzando con todo nuestro desarrollo de características. Y al mismo tiempo, tenemos un plan para mitigar este problema. Así que prácticamente este es el quid de la cuestión, como lo que quiero decir con esta charla, como, está bien, en lugar de luchar, ya sabes, contra la deuda técnica, en lugar de estar en este proceso donde cada vez que algo surge, 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 decimos, ya sabes, a tus gerentes de producto decimos, oh, necesitamos resolver esto porque es de mayor prioridad. Eso claramente acaba 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 base. Y al mismo tiempo, en lugar de hacer eso, ¿verdad? en lugar de decir, está bien, quiero erradicar toda la deuda técnica tan pronto como surja, estoy pensando en un marco para gestionar esto, ¿verdad? Para no ser paralizado por ello, para que no tengas que caer en el otro extremo donde, oh, ya no estamos haciendo ninguna refactorización, solo nos estamos centrando en las características y luego las cosas simplemente se acumulan, pero al mismo tiempo no ser muy reactivo a esto, como cada vez que algo surge, intentamos solucionarlo inmediatamente. Así que este marco intenta poner en su lugar todas estas cosas, ¿verdad? Y esto es lo que llamo los tres pilares de la refactorización, porque obviamente hay tres pilares, y vamos a repasarlos en un momento.

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 pase por todos ellos, espero que tengan sentido para todos.

Así que vamos a tomarlos uno a la vez. ¿De qué se trata las prácticas? Las prácticas son básicamente establecer ese objetivo 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 abordar, esta es la architecture, estos son los patterns, estas son las guidelines. Así que tienes, de nuevo, todas estas cosas, patterns y todo, tienes tu architecture.

Idealmente, también los tienes documentados, así que una buena práctica para hacer un seguimiento de estas prácticas es básicamente documentarlas. Puedes tener, ya sabes, formas en las que quieres estructurar tus archivos y tus carpetas, ¿quieres estructurar por funciones, estructurar por característica, 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 guidelines generales de codificación. Estas son cosas que no, realmente no puedes automatizar, ¿verdad? Son decisiones que simplemente surgen. Puedes imaginar que tienes un PR en algún momento y alguien se da cuenta, hey, hemos estado haciendo esta clase de lógica, así es como abordamos las cosas para este tipo de problema. Vamos a documentar esto como una práctica para que otros puedan leerlo y volver más tarde, podemos hacer referencia cruzada en otros PRs y decir, hey, decidimos hace tres meses que vamos a nombrar las cosas así o que vamos a usar esta abstracción particular de esta manera o como si tuvieras esto, deberías extraerlo en un componente separado. Todas estas cosas que realmente no pueden ser automatizadas y no siempre son como blanco y negro. Son más como, hay diferencias sutiles y hay cosas en las que tu equipo necesita decidir.

Así que la práctica es como establecer esta estrella del norte 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 la base de code debería estar o cuál es tu objetivo como equipo de ingeniería? Y luego el siguiente paso es, en mi mente es súper importante como el que la mayoría de las cosas son, creo que faltan, es como hacer un poco de casi como introspección en la base de code o investigación y averiguar qué nos falta, ¿verdad? ¿Cuál es la brecha a este ideal o a estas prácticas que tenemos en mente? Esto es lo que queremos conseguir, pero ¿dónde estamos ahora? Como, este es el inventario, tratando de averiguar qué falta, aquí es donde documentas, ¿cuál es tu deuda técnica? Ya sabes, ¿cuáles son las partes de la aplicación que necesitan ser actualizadas? Ya sabes, todas las cosas que necesitas, todos los pasos que necesitas hacer para llegar a ese escenario ideal. Así que, podrías tener cosas en tu backlog, por ejemplo, empiezas a documentar, hey, tenemos tareas específicas para actualizar algo, para cambiar una antigua forma de hacer las cosas por una nueva forma de hacer las cosas. Crear un nuevo componente, extraer un nuevo componente, deprecate un componente, deprecate 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 pudrirse 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 code que tienen esa creciente deuda técnica? Pueden ser cosas muy bajas, muy pequeñas, o pueden ser cosas más grandes. En este caso, empezamos a documentar incluso las cosas más pequeñas en este documento llamado contabilidad de deuda técnica. Siempre que introduces alguna deuda técnica o simplemente encuentras algo que de repente, te das cuenta, hey, esta es deuda técnica que no habíamos descubierto, la documentas en algún lugar. Y no solo vive en la cabeza de alguien que, hey, hay algún documento técnico allí. En realidad, está documentado en un lugar. Y una vez que llegas a eso, empiezas a construir prioridades. Y esta es en realidad una historia divertida. Este es code de producción que todavía tenemos. Tuvimos este viernes donde implementamos algo llamado la vista previa de Markdown, básicamente tomando archivos de Markdown y renderizándolos de manera agradable, formateándolos para la vista previa cuando navegas en la base de code. Y tomamos esto como una, fue casi como una experiencia de hackathon donde simplemente dijimos, okay, vamos a construir esto.

Teníamos esta idea, vamos a construirla. Y la lanzamos en un par de horas, un par de ingenieros. Y por supuesto el code es horrible y es solo una larga lista de callbacks y plugins sobre plugins y todo tipo de configuraciones rápidas extrañas, pero simplemente funciona.

Y esta parte particular de la aplicación, es un componente particular, pero está en el borde mismo de la architecture, ¿verdad? No es algo que la gente abrirá a diario para tener que navegar a través de él. No es como algo central, no es una experiencia central, ¿verdad? Incluso puedes desactivarlo si necesitas o es muy fácil, simplemente saca ese componente de eso y de repente los archivos markdown ya no tienen la opción de vista previa.

Así que empezamos, cuando empiezas a pensar en prioridades, tienes que entender, okay, no hay manera de que vaya a poder abordar todos los problemas en esta base de code. 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 la gente accede a diario y tiene que lidiar con él a diario, entonces sí, vamos a ponerlo con alta prioridad y a tratarlo lo más rápido que podamos. Si no, puede ser muy bien algo de baja prioridad o incluso puede ser ignorado. Incluso puede no estar en nuestro radar. No deberíamos centrarnos en esto en nuestro futuro proceso del que hablaremos en unos minutos.

Y finalmente, hablando también de inventario, también puedes añadir aquí planes, ¿verdad? Planificación para lo que hacer a continuación. Como, okay, tenemos... No solo que hemos descubierto deuda técnica, la hemos documentado y la hemos priorizado. Pero también podemos decir, okay, para esta deuda técnica particular, la solución es hacer lo que sea, reemplazar el antiguo componente, el componente legado con el nuevo componente. Deprecar este caso de uso, extraer algunos nuevos subsistemas o subcomponentes de eso. La planificación de este tipo se puede hacer, no sé, a través de RFCs o cualquier tipo de documento que explique estos son los pasos que necesitamos tomar 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 el objetivo. Creo que ya lo he mencionado, ¿verdad? Este es el objetivo que tienes. Aquí es donde necesitamos ir. Esto es lo que establece las expectativas de todo el equipo de que aquí es donde llegaremos con la base de code. Y el inventario es como darte la dura realidad, si quieres, ¿verdad? Aquí es donde estamos ahora. Estamos tan lejos de nuestras prácticas ideales. Así que con la planificación y con todos los pasos tomados, ¿verdad? Con documentos en ambos lados, con expectativas claras y comprensión clara y todo compartido dentro del equipo que esto es, ya sabes, este es nuestro, así es como procedemos con esto.

Entonces el proceso siendo el tercer pilar del que hablaremos en un segundo es como el paso de llevar todo del estado actual al siguiente estado, ¿verdad? Casi como de A a B. Y por eso en el plan también es parte del inventario porque te dará los pasos iniciales. Sí, para abordar esta deuda técnica particular, necesitamos hacer esto, para, ya sabes, pasar del sistema legado al nuevo sistema, necesitamos abordar esto y aquello. Así que es muy importante si tienes estos dos pasos previos, ¿verdad? Si has hecho tu investigación, si has documentado las cosas, y si el equipo está de acuerdo en las formas de avanzar, entonces el proceso se parece mucho al proceso de cualquier característica de web development, ¿verdad? O cualquier característica de producto para el caso. Como tienes ejecución, ¿verdad? Tienes propiedad, alguien se asigna a una tarea particular. Okay, necesitan cambiar algo, necesitan arreglar un área particular del code. El tiempo también se tiene en cuenta porque hemos priorizado las cosas, hemos planificado soluciones.

Entonces sabemos, está bien, mitigar esta deuda técnica particular podría llevar una semana, podría llevar una hora, podría llevar más tiempo. Depende, por supuesto, de la complejidad de la misma. Y también tienes el progreso, ¿verdad? Cada semana, ya que has planificado las cosas, ya que trabajas con un objetivo claro en mente, también puedes calcular bastante bien este es el progreso, estoy a mitad de camino, ¿verdad? Todavía necesitamos tiempo, o casi he terminado. Así que esto trae, el proceso es algo así como muy similar a cualquier otra característica. Por lo tanto, puede ser muy bien una característica de producto, puede ser una característica de ingeniería, o como una tarea de ingeniería como esta. Puedes verlas a través del mismo tipo de lente aquí.

Así que 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? Piénsalo, si no tienes las prácticas en su lugar, realmente no sabes a dónde vas, como que estás refactorizando en vano, como, está bien, estoy refactorizando por el bien de ello. Sabes, solo sé que esto no está bien, pero realmente no sé dónde parar. ¿Cuándo es suficiente, verdad? ¿Cuándo es la calidad de ese code o de esa architecture lo suficientemente buena para mí? Si no tienes el inventario, entonces realmente no sabes qué recoger. Empiezas a refactorizar partes de tu aplicación. Y de nuevo, el inventario es súper importante porque a menudo es pasado por alto por los equipos. Y terminas con alguien recogiendo alguna tarea, queriendo refactorizar algo, pasando por toda la base de code, pero perdiendo trozos de partes del code que ni siquiera se tienen en cuenta porque nadie lo documentó. Oye, hay algunos problemas allí. También necesitamos abordar eso. Eso también es legado, no solo, ya sabes, el camino principal que fue refactorizado. 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 ser dueño de esto y demás.

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

Entonces, la regla número uno es hacer estas cosas visibles, ¿verdad? Realmente no puedes refactorizar en la oscuridad. Existe este malentendido común de que, ya sabes, la gente simplemente debería refactorizar las cosas por su cuenta, ¿verdad? Cuando encuentran algo, simplemente lo refactorizan rápidamente sin que el PM se entere de ello porque el enfoque está estrictamente en el desarrollo del producto. Necesitas ser muy transparente sobre esto, y siento que todo debería estar a la vista, ¿verdad? Debería haber tareas claras para la refactorización que se tienen en cuenta cuando estás haciendo la planificación del ciclo cuando estás haciendo la planificación de la iteración, cuando cuentas la cantidad de tiempo que la gente pasará en el proyecto y así sucesivamente. No hay nada 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 muy claramente definidos como PRs de refactorización, ¿verdad? No solo deslizamos algún trabajo de refactorización en un PR de característica porque entonces, por supuesto, te arriesgas a estropear las cosas y te arriesgas a retrasar la característica en sí. Así que intentamos separar. Cuando encontramos deuda técnica incluso es de alta prioridad necesitamos refactorizar esto inmediatamente. No hacemos eso en ese PR, simplemente abrimos otro como un PR de seguimiento y abordamos esa cosa. Y está claramente marcado como un PR para refactorizar porque entonces se revisa de manera diferente, ¿verdad? Con diferentes ojos tienes diferentes enfoques para mirar el code que se refactoriza en lugar de code que simplemente añade algo o arregla algo que es, ya sabes de más valor para el producto que para la base de code. La segunda regla es hacerlo gratificante. Ahora es muy importante que la gente tenga una sensación de éxito de la refactorización y de lidiar con la deuda técnica de la misma manera que lo hacen al enviar algo, ¿verdad? Obtienes, cuando trabajas en un equipo de producto cuando envías algo, obtienes un nuevo lanzamiento obtienes esa, ya sabes, esa buena vibra de que, oye, enviamos esto, lo logramos, es una historia de éxito.

Entonces, lo que hacemos en Code Sandbox, también celebramos, ya sabes cualquier tipo de éxito, que puede ser incluso como, está bien nos deshicimos de una tonelada de code el viernes. Esto es algo que recientemente recién empecé. Siempre, tienes en nuestro canal de Slack siempre, ya sabes, en diferentes bases de code la gente está diciendo, hey, acabo de, ya sabes 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 se ha ido y es perfecto. Y tratamos de celebrar junto con el equipo y lo vemos como un éxito.

Otra forma de celebrar, y en realidad una cosa divertida que hacemos desde finales del año pasado es que intentamos deshacernos básicamente del code que no nos trae alegría. Y llamamos a esto la Marie Kondo de la base de code. Entonces, nos reunimos en nuestra oficina virtual una vez cada viernes más o menos. Y decimos, hey, necesitamos manejar necesitamos manejar estas partes particulares de como tenemos algo de code que existe desde hace un tiempo realmente no aporta mucho valor. Podemos eliminarlo. Incluso si es una pequeña característica que tal vez está olvidada en algún lugar. Si sabemos que ya no se usa simplemente nos deshacemos de ella. Si hay componentes que no se utilizan si hay componentes que no están al mismo nivel que otros componentes en el sistema de design, intentamos simplemente nivelar y lo que sentimos es como que tenemos esa picazón de que sí, esto necesita desaparecer. Necesitamos una mejor manera de hacer esto o simplemente necesitamos eliminar esto. Entonces lo hacemos en estas sesiones. Así que terminamos documentando todo esto de nuevo y manteniendo un seguimiento. Y cada mes intentamos pasar tanto tiempo como sea posible simplemente haciendo esta limpieza. Simplemente sacar estas cosas del sistema sacar estas cosas de la base de code y mantener la deuda técnica y mantener todas estas cosas legadas que al final del día al mínimo.

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

Lo que hacemos aquí para hacerlo resiliente es que intentamos mantenerlo bajo control. Siempre que pasamos por un período de más desarrollo de características, todavía tenemos estas reuniones y tenemos estas reuniones de grupo con todo el equipo horizontal, como trabajar con front end incluso si trabajamos en diferentes equipos de producto. Y nos juntamos y decimos, hey, en esta code base todavía tenemos este problema. No hemos tenido tiempo para hacer nada con él pero este es el plan. Lo estamos impulsando hacia adelante. Hemos documentado cosas nuevas. Intenta estar en control. Intenta que todos en el equipo, sean conscientes de que este proceso todavía está allí incluso si está en baja prioridad por el momento.

Y por supuesto, cuando tienes la prioridad para eso, haz estas reuniones más accionables. Asigna una propiedad clara. X puede ocuparse de actualizar algunas pruebas antiguas. Y puede agregar nuevos componentes al sistema de design, estandarizarlos porque los usamos en varios lugares. Hay toneladas de ejemplos como estos que puedes hacer cosas accionables que puedes hacer semanalmente. Así que estas eran las reglas y este es el proceso que tengo en mente y el framework que tengo en mente para construir esta cultura de refactorización.

Quiero dejarte con una cita que adapté y eso es que, cada equipo tiene una persona que impulsa esta cultura de refactorización y si no sabes quién es, entonces probablemente eres tú. Quiero animar a todos a llenar este vacío si sientes que no hay nadie, ya sabes, impulsando este esfuerzo, requiere un poco de esfuerzo esa fuerza para ser el conductor, 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 abrazar esto como una cosa cultural, no solo como algo que una sola persona impulsa. Muchas gracias y feliz refactorización. Y estoy súper contento de ver a Marie Kondo de nuevo en acción y no sacarla del escenario o de los escritorios. Veo que están caminando en la oficina. ¿Cómo estás hoy? Estoy bien, gracias. Y muchas gracias por tenerme. Vamos a la diapositiva, la pregunta que preparaste para nosotros y veamos los resultados. ¿Cómo te sientes al respecto? Algunos, bueno, el 46% de las personas dijeron que tienen más del 20% del tiempo asignado y el 37 entre el 10 y el 20% del tiempo. Por supuesto, parece que están fluctuando un poco. Así que 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 muy buen indicador de que la industria crece hacia más, no sé, software sostenible, todo se siente un poco más organizado. Parece que hemos crecido desde ese período de gerentes diciendo que no tienes que escribir pruebas.

Simplemente haces un buen trabajo y luego el code se prueba a sí mismo y cosas así. Creo que es un indicador positivo de que la gente reconoce que necesita al menos más tiempo para mantener las cosas bajo control y asegurar que el proyecto basado en código y una pieza de tecnología crezca de manera constante.

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

También tenemos algunas preguntas de la audiencia y voy a pasar a ellas. Y la primera sería, ¿qué herramienta estás usando para pasar por 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 ayudan en estos procesos, desafortunadamente, es un proceso bastante centrado en el humano porque en mi mente, vale, si tienes herramientas, por ejemplo, para cosas de las que hablé, como mantener un cierto nivel de code calidad de las guidelines de codificación. Si hay cosas que pueden ser automatizadas entonces ni siquiera vale la pena mencionar el proceso. Como que simplemente tienes todos los formateadores, tienes linters, tienes pipelines de CI que de alguna manera validan todo y simplemente mantienen las cosas bajo control.

Para todo lo que no puede ser automatizado, significa que tampoco hay realmente una herramienta que pueda resaltar cosas. Puedes empezar a mirar cosas como la code complejidad, pero yo diría, siempre toma eso con un grano de sal, asegúrate de que no es como, no solo puedes, puedes tener herramientas que te ayuden, pero nunca puedes confiar 100% en las herramientas si hay cosas que no pueden ser totalmente automatizadas. Por ejemplo, confiamos en cosas como el node prune es un paquete que puedes ejecutar en bases de code más grandes para simplemente darte paquetes y modules que no se usan, que a veces algunas de esas cosas no se ven fácilmente. Entonces, hay algunas soluciones por ahí, pero desafortunadamente diría que la gran mayoría de los procesos de los que hablé son de alguna manera manuales y requieren algún tipo de propiedad humana, por así decirlo.

En efecto, en efecto. Y ahora que mencionaste la perspicacia humana, Marie Kondo recibió apreciación. Ah, genial. La gente dijo que les encantó que lo llamaras el método de Marie Kondo, pero parece que esta persona no tiene necesariamente problemas para convencer al lado empresarial de que necesitan hacer la profundidad técnica. Pero en general, ¿cuál sería tu enfoque para convencer al gerente de producto, al propietario del producto de que la profundidad técnica debería ser considerada más y no debería ser simplemente descartada?

Bueno, creo que la respuesta clásica, una 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 lo convencerás más probablemente con algún tipo de números, gráficos, como la idea de que hey, ya sabes, hace seis meses o un año estábamos enviando características a este ritmo, ahora estamos enviando a ese ritmo, y como, esta es una diferencia. Y esto es, ya sabes, claramente tenemos un problema, ya sabes, la developer experience ha estado disminuyendo 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 a bordo en esto, así que es más como sobre la propiedad. Como que más, la mayoría, es más como sobre nosotros teniendo que tomar la propiedad para hacer el proceso en lugar de tener que pedir permiso para ello o algo así. Pero sí, siempre hay, creo que siempre hay métricas que puedes sacar de la rapidez con la que la gente está entregando. También puedes obtener simplemente, obtener la sensación de cómo se siente el equipo acerca de las cosas. Simplemente ten, si estás en posición de hacerlo, ten una conversación uno a uno con cada ingeniero del equipo y simplemente haz que las preocupaciones comunes se expresen para todos. Así que está claro que es como 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 la persona del producto, la persona del producto verá que algo está yendo mal por esto. Y literalmente recibimos 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 tener lugar durante mucho tiempo el desarrollo de características, lo que significa que mencionamos que podemos decidir y poner este tiempo pero para el producto podrían literalmente quitar eso de la mesa. ¿Por qué debería ser distinto y visible para los equipos de producto?

Entonces, cuando digo equipos de producto, quiero decir, debería ser visible para todos los que están preocupados por ellos. Así que no es como, ya sabes, algún ingeniero en la sombra hace la refactorización y otros simplemente lo aprueban.

Al final, ellos dicen, hey, buen envío allí. Simplemente cubrámoslo en algún lugar. Se trata más de que seamos transparentes en que es solo parte del trabajo. De la misma manera que 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, yo diría.

Por lo tanto, no necesariamente tiene que ser visible para el gerente de producto o propietario del producto o completamente transparente para ellos, pero deberían saber que así es como opera el equipo. Y también transparente con la disponibilidad de uno mismo. Estas pocas horas se invertirán allí. No es que no estén haciendo trabajo de producto por nada. Es que mi disponibilidad estará dividida entre esto.

Realmente, una charla muy perspicaz Alex. Y estoy realmente contento de que hayas compartido todas las ideas y los procesos que has establecido con este framework. Muchas gracias por acompañarnos 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.