Depuración de JS

Este es Mark Ericsson, y hoy estoy emocionado de hablarles sobre debugging JavaScript. Advertencia justa, probablemente tengo unos 40 minutos de contenido y como 20 minutos para pasar por él, así que voy a ir un poco rápido.

Las diapositivas ya están en mi blog, blog.isquaredsoftware.com. Siéntanse libres de abrirlo y seguirlo, o echarle un vistazo más tarde.

Un par de cosas rápidas sobre mí. Soy un ingeniero senior de frontend en Replay, donde estamos construyendo un depurador de viaje en el tiempo para JavaScript. Hablaremos más sobre eso en unos minutos. Respondo preguntas en cualquier lugar donde haya un cuadro de texto en internet, recojo cualquier enlace que parezca potencialmente útil, escribo publicaciones de blog extremadamente largas, y soy un mantenedor de Redux, pero la mayoría de la gente me conoce como ese tipo con el avatar de los Simpsons.

Esto no es una charla de Redux, pero tengo una noticia relacionada con Redux. Hace dos días, mientras estaba en el aeropuerto, publiqué Redux Toolkit 2.0 Beta. Tenemos una serie de cosas que estamos tratando de lograr en 2.0, la mayoría tiene que ver con la modernización del formato del paquete y el contenido del JavaScript. Hemos eliminado un par de APIs obsoletas. Hemos añadido varias APIs nuevas. Lo más importante que pediría es que realmente nos gustaría que la gente lo probara en sus aplicaciones ahora mismo, vean cómo funciona, denos su opinión, díganos qué cosas se rompieron, díganos si las APIs están funcionando, para que podamos avanzar hacia la versión final 2.0. No tengo un cronograma concreto. Espero que en los próximos meses, si todo va bien.

Muy bien. Hablemos de debugging. La debugging es el proceso de encontrar problemas en tu programa e intentar averiguar qué está pasando. En otras palabras, ¿por qué está roto? ¿Y cómo lo arreglamos?

Ahora, como programadores, pasamos mucho tiempo haciendo cosas que no son solo escribir code. Estamos comunicándonos con nuestro equipo. Estamos haciendo planificación, design, discusiones, revisión de code. Pasamos mucho tiempo intentando averiguar por qué el code que escribimos no está funcionando. Y sin embargo, muchos desarrolladores no se sienten cómodos haciendo esto. Y he pensado un poco en esto. Creo que el mayor problema es que nuestra industria no enseña a las personas cómo debug. ¿Cuántos de ustedes tienen un título en ciencias de la computación y sin embargo nunca tuvieron un curso de debugging? Para mí, la debugging es una habilidad absolutamente crítica para los desarrolladores. Y la buena noticia es que es algo que puedes aprender y mejorar.

Entonces, veamos algunos principios básicos de la debugging. Ahora, el título de la charla es debugging JavaScript. Estos principios son universales. Puedes aplicarlos a cualquier lenguaje y francamente puedes aplicarlos fuera de la programación también. Y el primero es que cada problema tiene una causa y una razón. Y debería ser posible averiguar por qué esta cosa está rota. Ahora, solo porque haya una causa no significa que vaya a ser fácil averiguarlo. Y hay muchas cosas que pueden complicar eso. Pero es posible. Otro es que es muy importante entender lo que se supone que debe hacer el sistema. Si un bug es algo que está mal con el sistema, tienes que saber lo que se suponía que debía hacer en primer lugar para ver que el comportamiento es incorrecto. Otro principio es que reproducir un problema es absolutamente clave. Por un lado, necesitas poder averiguar qué área del code está rota, y eso a menudo requiere un proceso de prueba y error de hacer que esta cosa se caiga una y otra vez y otra vez pero también es importante porque una vez que crees que tienes una solución, necesitas poder probar los mismos pasos y verificar que realmente funciona bien. También necesitas poder debug con un plan. Este es básicamente el método científico. No solo vayas cambiando variables aleatorias y esperando que de alguna manera vaya a mejorar. Necesitas ser muy cuidadoso e intencional sobre los cambios que haces, prueba una cosa a la vez, ve si los cambios de comportamiento realmente coinciden con lo que esperas que sea y trata de reducir dónde y por qué algo está saliendo mal. Otro problema es que los errores proporcionan información útil y sin embargo, la gente a menudo entra en pánico cuando ven esa gigantesca traza de pila.

He visto imágenes de una traza de pila de React que está minimizada y no puedes leer nada o una traza de pila de Java J2EE que tiene 500 líneas de largo y tu code son dos líneas en algún lugar en medio. Ahora, en algún lugar de allí, hay información útil, tu code, tu archivo, línea 37, en algún lugar, pero los errores te dicen algo sobre lo que está saliendo mal. No entres en pánico, intenta entenderlo.

Y sí, literalmente, buscar en Google tu error es un buen primer paso. Hay una cita muy famosa de una de las aventuras del sistema operativo UNIX en el lenguaje C donde dice, la debugging es dos veces más difícil que escribir un programa. Así que si escribes code realmente inteligente, probablemente no seas lo suficientemente inteligente para descifrarlo tú mismo. Así que intenta escribir code que sea claro y fácil de entender para que algún tiempo después tú o uno de tus compañeros de equipo o ese becario dentro de cinco años pueda entender qué estaba sucediendo.

En general, los pasos para la debugging parecen algo así. Primero tienes que entender ¿cuál es la descripción? Alguien presentó un informe de error. ¿Qué están intentando decir realmente que está mal? Segundo, reproduce el problema. Tienes que ser capaz de encontrar pasos reproducibles que hagan que el error ocurra. Abre la aplicación, haz clic en esta pestaña, haz clic en ese botón, kaboom. Luego, y esta es la parte difícil, intenta averiguar por qué está sucediendo. Una buena táctica es algo así como una búsqueda binaria. Tenemos una aplicación completa. ¿Puedo reducirla a la mitad de la aplicación? ¿Un cuarto? ¿Un octavo? Trabaja tu camino, intenta reducir dónde en el code está sucediendo esto. Una vez que realmente crees que sabes lo que está sucediendo y has identificado algunos de los síntomas, no te detengas allí. Sigue adelante e intenta averiguar si hay un problema de causa raíz más profundo que está sucediendo. Una vez que sabes lo que está saliendo mal, entonces puedes intentar averiguar cuál es la mejor solución para intentar solucionarlo. Y aquí es donde entran las restricciones. Tal vez sea una solución de una línea. Tal vez crees que necesitas reescribir todo el subsistema, pero no tienes tiempo porque tu equipo ya está sobrecargado. Tal vez el code es realmente complicado. Intenta averiguar cuál es la cantidad correcta de esfuerzo necesario para hacer la corrección apropiada. Luego, soluciónalo de verdad. E idealmente añade más pruebas y controles para que esto no suceda en el futuro. Y finalmente, intenta documentar tanto como sea posible, ya sea en el mensaje de commit, el PR, el problema, deja información para las personas para más tarde para que entiendan qué salió mal y cómo lo solucionaste. Un par de otros consejos. Utiliza la herramienta adecuada para el trabajo. Hay muchas herramientas diferentes para usar para la debugging.

Hablaremos de algunas de ellas en un segundo. Cuantas más herramientas tengas en tu caja de herramientas, mejor equipado estarás para intentar resolver problemas. Otro es que usamos muchas bibliotecas diferentes y paquetes y frameworks. A menudo los tratamos como cajas negras. Esté dispuesto a mirar debajo del capó y entender lo que está pasando dentro. Porque a menudo entender ese comportamiento hace posible ver cuál es el verdadero problema.

Otro es simplemente no tener miedo. Ves esa gigantesca traza de error, o es una parte del sistema en la que nunca has trabajado antes. Podrías entrar en pánico, especialmente si eres nuevo en el equipo. No tengas miedo. Tómate tu tiempo. Piénsalo. Es algo que puedes descifrar. Y esto es algo con lo que lucho. Es muy fácil quedar atrapado y perseguirlo. Estoy a punto de arreglarlo. Estoy a punto de arreglarlo. Y quedarse atascado. Hay momentos en los que simplemente necesitas alejarte, tomar un respiro, dormir un poco, volver al día siguiente. Ha habido momentos en los que lo arreglé en cinco minutos a la mañana siguiente después de estar atascado durante horas el día anterior.

Muy bien. Voy a tener que seguir adelante. Hay mucho debate sobre si debo usar declaraciones de impresión o depuradores gráficos? Y yo digo, ¿por qué no ambos? Ambos son herramientas maravillosas. Las declaraciones de impresión son muy fáciles de añadir. Te muestran los cambios en el sistema a lo largo del tiempo. Los depuradores gráficos te ayudan a centrarte en un trozo específico de code y a pasar por él paso a paso e inspeccionar el contenido del programa en ejecución. Ambas son excelentes herramientas para tener en tu caja de herramientas. Los diferentes lenguajes tienen diferentes tipos de declaraciones de impresión disponibles. Puedes tener marcas de tiempo. Puedes tener diferentes niveles de registro.

En JavaScript, esto se hace principalmente con los métodos de console o puedes tener una biblioteca de registro como Winston. Hay diferentes métodos para diferentes niveles. La API de console también tiene cosas que te permiten hacer como imprimir objetos como una tabla, agrupar mensajes juntos. Un problema común que veo es que la gente registra un objeto o un array, y algún tiempo después lo expanden y el contenido parece diferente. En realidad te muestra lo que contenía en el momento en que lo expandiste, no en el momento en que lo registraste en primer lugar. Esto confunde a mucha gente.

Además, la mayoría de las bibliotecas de JavaScript se distribuyen como archivos fuente en disco en los modules de node. Puedes editarlos tú mismo, pero, como, trata de recordar eliminar las declaraciones de registro más tarde. La mayoría de los depuradores gráficos tienen los mismos tipos de comandos y botones en su interior. Los puntos de interrupción te permiten pausar en un cierto punto del programa. Normalmente establecerías esos haciendo clic izquierdo en un número de línea. Por lo general, hay paneles que muestran el contenido de las variables en el ámbito, algo que muestra las funciones de la pila de llamadas, y algunos botones que te permiten avanzar, entrar, salir. Como un par de ejemplos, las DevTools de Chrome tienen todos esos comandos. Tienes los puntos de interrupción y el ámbito y la pila de llamadas en el lado derecho. Tienes un marcador de punto de interrupción allí en la línea izquierda. VS Code tiene básicamente todos los mismos botones, solo que en diferentes lugares. Estas son todas piezas muy comunes para cada IDE y cada depurador.

Veamos, vamos a saltar un poco de esto. Un par de consejos para la depuración de React. Lo más importante es entender cómo funciona el modelo mental de React con los componentes y el flujo de datos. React renderiza componentes, los padres pasan datos como props a sus hijos, los hijos pasan datos de vuelta a sus props a través de funciones de callback. Si tu UI, si lo que ves en la pantalla está mal, o tus datos estaban incorrectos o la lógica de renderizado estaba mal, si la lógica de renderizado está bien, mira los datos. ¿De dónde vienen? Vinieron del padre, vinieron de Redux, vinieron de Apollo. Rastrea los datos hasta donde los encontraste.

Asegúrate también de usar las React DevTools. La extensión del navegador React DevTools te mostrará el árbol de componentes, te permite seleccionar un componente, inspeccionarlo y mirar sus props, estado y hooks. De manera similar, con Redux, es muy importante entender el flujo de datos de Redux, despachas acciones, los reducers actualizan el estado, la UI se vuelve a renderizar. De manera similar, hay una extensión Redux DevTools que te muestra el historial de las acciones despachadas. Para cada acción, puedes inspeccionar el contenido de la acción, el contenido del estado y la diferencia del estado. Como resultado de eso, todas estas son herramientas muy valiosas para tener en tu caja de herramientas.

Vale. Podríamos lograr esto más o menos a tiempo. Muy bien. Así que, discurso de venta de trabajo corporativo. Mi trabajo diario es trabajar para Replay. Lo mencioné. Y estamos construyendo un verdadero depurador de viaje en el tiempo para JavaScript. Es algo irónico, porque el discurso de venta original de Redux era la depuración de viaje en el tiempo, y eso es. Replay es eso como multiplicado por un millón. Una de las partes más difíciles de la depuración es que tienes que ser capaz de reproducir el problema. Y a veces eso puede llevar muchos pasos. Y estás pausado en un punto de interrupción, avanzas, te sientas, vaya, fui una línea demasiado lejos. Y ahora tienes que detener el programa y reiniciarlo y volver hasta el punto donde estabas. Y es un dolor. O el error solo ocurre en esa máquina de un desarrollador de QA un martes de febrero o algo así. Así que la idea de Replay es que te permitimos grabar un error una vez. Y luego usar la depuración de viaje en el tiempo para entender lo que realmente sucedió en eso.

El flujo de trabajo básico, descargas nuestras versiones de Firefox o Chrome, grabas el error, haces que suceda una vez, lo subes a la cloud, abres la grabación en la UI, y ahora puedes inspeccionar la grabación en cualquier punto en el tiempo. Puedes saltar a cualquier línea de code, puedes ver cuántas veces se ejecutó, puedes añadir console registros e instrucciones de impresión después del hecho, y puedes usar la depuración paso a paso para inspeccionar las cosas.

También hay colaboración donde puedes añadir comentarios, hacer que tus compañeros de equipo vean lo que estaba sucediendo, e incluso compartir las instrucciones de impresión que has añadido. Replay es gratuito para código abierto e individuos. De pago para empresas donde somos una startup, estamos tratando de ganar dinero realmente.

Muy bien. Ahora, la parte divertida. Vamos a hacer una demostración en vivo. Vamos, Wi-Fi. Okay. Bueno. Primer paso. Entonces, esta es la interfaz de usuario de Replay. Esta es una grabación que hice hace bastante tiempo del ejemplo del tutorial de Fundamentos de Redux. Entonces, tenemos el visor. Puedo ver cómo se veía la aplicación en el momento en que se grabó. Puedo saltar a un par de puntos diferentes en el tiempo y ver cómo se veía la interfaz de usuario. Pero puedo cambiar al modo DevTools. Y esto es básicamente como las DevTools del navegador Firefox en un navegador, porque eso es realmente donde comenzó nuestra base de código.

Entonces, esta es una aplicación Redux. Probablemente estoy interesado en los reductores. Así que vamos a encontrar el fragmento de los 'todos'. Lo primero que noté cuando abrí esto es que, además de los números de línea, tenemos todos estos recuentos de golpes. Y esos me están diciendo cuántas veces cada línea de code se ejecutó durante la grabación. Y esto empieza a decirte información útil, como tal vez esperaba que la línea se ejecutara cinco veces, pero en realidad se ejecutó como 100 veces. Eso no es bueno. O tal vez esperaba que entrara en la declaración if, pero no lo hizo. ¿Por qué? Entonces, puedo mirar el code y puedo ver que, en este ejemplo, el reductor 'todo toggled' se ejecutó, parece, tres veces. Okay, así que ahora tengo curiosidad sobre lo que estaba pasando dentro de eso. Así que puedo hacer clic en este signo más y te das cuenta de que aquí a la derecha tenemos lo que parece tu típica consola de navegador.

Y te das cuenta de que tenemos tres mensajes allí. Y eso es porque esa línea de code se ejecutó tres veces, y está evaluando el mensaje en cada línea. Entonces, ¿qué pasa si quiero decir, como, aquí está el nombre de la función, y quiero ver qué era el objeto de acción en cada uno de esos. Así que he editado la declaración de impresión, y la está evaluando. Ahí está la cadena y todo el objeto de acción. Y puedo expandirlo y echar un vistazo.

Bueno, ¿y si quiero saltar a un punto en el tiempo? Podría, por ejemplo, hacer clic en uno de estos, y ahora estoy pausado como un paso normal depurador dentro de esta función, y puedo mirar los valores que están en el alcance, puedo pasar el ratón sobre ellos, puedo inspeccionarlos, y tenemos el vamos a ver tenemos toda una pila abajo aquí en algún lugar. Así que podemos ver que esto fue desencadenado por algún tipo de manejador rápido de React, y estamos dentro del code de Redux.

Otra cosa que tenemos es que hay una lista de todas las diferentes veces que presioné una tecla o hice clic, y si paso el ratón sobre esto, hay un botón de saltar al code. ¿Qué hace eso? Bueno, me acaba de saltar directamente a la línea de code donde despaché donde hice un clic, ahí está mi manejador de propiedades on click, y ahora puedo empezar a inspeccionar el code aún más. Incluso tenemos el árbol del DOM en ese punto en el tiempo, y el árbol de componentes de React en ese punto en el tiempo. Y así ahora puedo pasar por toda la grabación, puedo ver qué pasó, saltar hacia atrás y hacia adelante, inspeccionar el sistema, y sólo tuve que hacer la grabación una vez. Me estoy divirtiendo mucho construyendo esta aplicación, y realmente creo que es un cambio revolucionario en cómo depuramos. Así que por favor, échale un vistazo, te ahorrará mucho tiempo. Ojalá lo hubiera tenido hace años. Muy bien. Eso es todo lo que tengo, y básicamente terminé a tiempo. Eso es impresionante. Como dije, las diapositivas están en mi blog, tengo enlaces a un montón de recursos adicionales sobre depuración. Por favor, ven y di hola, haz preguntas sobre Redux o replay o depuración o lo que sea. Muchas gracias.

Muchas preguntas, ¿por dónde empezamos? Aquí vamos. ¿Replay solo funciona con Redux o también con React puro? Replay funciona con todo. Replay funciona grabando el navegador hablando con el sistema operativo. Así que literalmente cualquier cosa que se ejecute en el navegador, Replay lo ha grabado. Tenemos algunas integraciones específicas de React, como las herramientas de desarrollo, pero no importa si estás usando React, Vue, Angular, JS puro, lo que sea, si se ejecutó en el navegador nosotros con las excepciones de WebGL y audio aún no podemos hacerlo.

Esta es una pregunta divertida. ¿Es esta la nueva herramienta de desarrollo y podemos reemplazar completamente la antigua? Sí, no, tal vez. La verdad es que el mayor punto de fricción con Replay en este momento es que tienes que pausar y hacer la grabación y luego abrirla por separado. Cuando estoy trabajando en una característica, todavía estoy usando las herramientas de desarrollo del navegador para investigar eso mientras estoy escribiendo el code. Una vez que he escrito algo, entonces usar Replay para investigar lo que pasó después es mucho más fácil. Tiene sentido.

Esto es muy interesante. ¿Puede Replay ofuscar datos sensibles o confidenciales antes de enviar el replay a la cloud? Creo que tenemos una capacidad muy limitada para ofuscar en este momento. Creo que una mejor versión de eso está en nuestro mapa de ruta para finales de este año, principios del próximo, creo. Genial. Estaría muy emocionado por eso. Esperemos. Espero que no me lo tomes a mal. No. No es contractual. Oh. Esta es una buena. ¿Usas console log? Yo uso console log, yo debug. Como dije, depende de cuál sea la situación. Los registros son geniales para ver paso a paso lo que pasó en mi aplicación, la depuración GUI, los depuradores son buenos para profundizar en una pieza en particular, así que hago ambas cosas. Soy un gran fan de console log. Tú y mucha otra gente. Lo sé.

Es solo para los rápidos, ¿sabes? Respondimos a esa. ¿Puede Replay ser utilizado con code minificado? Absolutamente, sí. Así que lo mismo que dije hace un minuto, Replay registra lo que sucedió en el navegador. No importa si es una construcción en modo de desarrollo, construcción en modo de producción, lo que sea. De hecho, en Replay, ayer en JS Nation, Jesselyn Yeen dio una gran charla sobre debugging y mencionó los mapas de fuente que le dicen al depurador cómo se veía el code minificado. Aquí está cómo se veía el code original. Y nos encantan los mapas de fuente en Replay. Así que Replay también depende de los mapas de fuente. Si tu aplicación tenía mapas de fuente junto a ella, registra el code minificado que se ejecutó pero nosotros luego usamos los mapas de fuente para mostrarte la aplicación original. Un par más en el tema de ¿esto funciona con? He visto electron, he visto ¿funciona para debug el backend, um, espera había uno más. ¿Qué pasa con las aplicaciones basadas en canvas y qué pasa con wasm? Bueno, ahora mismo, el navegador de grabación principal de Replay es nuestro fork de Firefox que funciona para Mac, Windows y Linux. Tenemos soporte de Chrome para Linux que es bastante bueno. Nuestro objetivo principal para eso ahora mismo es el uso de CI. Tenemos, tenemos versiones alfa tempranas de Chrome para Windows y Mac también. Tenemos soporte de Node para Linux a nivel alfa. Lo he usado para grabar algunas pruebas de jest y debug ellas. Nuestro objetivo es llevar el soporte de Chrome a toda velocidad en los próximos meses y hacer de ese nuestro navegador de grabación principal. Queremos hacer Electron eventualmente pero eso necesita esperar hasta que Chrome esté terminado y luego probablemente después- ¿Qué pasa con una situación de plugin de VS Code? Hipotéticamente algún día. Hipotéticamente algún día. Una pregunta más y luego te enviaré a tu stand. ¿Ya estás debugging Replay con Replay mismo? Oh, Dios mío. Así que te lo dije. Me uní a esta empresa porque creo en esta herramienta. Y rutinariamente usamos Replay para debug Replay. Como básicamente cada problema que presentamos internamente necesita tener una grabación de Replay adjunta al problema. Has visto la película Inception. Hay veces donde como cuatro o cinco niveles de grabaciones profundas sabes un replay de un replay de un replay de un... A veces es difícil llevar la cuenta de ¿a qué nivel estoy intentando debug aquí? Muchas gracias por tu tiempo. Y gracias por compartir Replay con nosotros. Mark estará en su stand después de esto en la parte de atrás. Así que otro gran aplauso por favor.