Resumen
El episodio 52 de enCoders, que cierra el primer año del podcast, trata sobre técnicas de debugging aplicadas a ciencia de datos y su uso en Visual Studio Code. Se explica el origen del término "bug" y se repasan tips generales: hacerse las preguntas correctas, leer errores y documentación, usar logs y prints, localizar el problema con búsqueda binaria, replicarlo de forma mínima, preguntar a la comunidad, hacer tests y apoyarse en linters. Los presentadores coinciden en que el preprocesamiento de datos es donde más se debuggea y en que los errores más difíciles son los que no hacen caer el programa pero dan resultados sin sentido. En la demo con Python se muestran breakpoints condicionales, hit count, logpoints, consola de debug y variables locales/globales. Hay desacuerdo sobre si conviene "desmembrar" funciones para depurarlas, y se concluye que conviene hacer chequeos preventivos de los datos y variables creadas. También se anuncia un episodio especial por el aniversario.
Capítulos
- 00:00IntroBienvenida al episodio 52, que cierra el primer año del podcast, y presentación del tema: debugging.
- 00:16Qué es y de donde viene el debuggingEl término viene de cuando insectos reales se metían en computadores enormes y los hacían fallar. Importa porque se pueden perder horas buscando un error, y todos los programadores, con cualquier nivel de experiencia, cometen errores.
- 02:36Tips generales para debugearLos tips salen de un artículo y de un video de FreeCodeCamp (cuyo nombre el ASR transcribe como "F chip"), que se dejarán en las referencias. Son útiles sobre todo para perfiles junior.
- 03:08Preguntarse las buenas preguntasPara resolver un problema hay que entender qué se obtiene y qué se quiere obtener. Según el presentador, en ciencia de datos se debuggea sobre todo en el preprocesamiento de datos, más que en el modelo. Otros dicen que también al aprender o configurar herramientas nuevas.
- 06:15Leer los mensajes de error y documentaciónMuchos errores se resuelven leyendo el error o la documentación (parámetros mal usados, versiones distintas de la librería). Se debate si pegar el error directo en ChatGPT: se recomienda leer primero, porque ChatGPT no ve tu ambiente. Con más tiempo conviene leer la documentación para entender el contexto completo.
- 13:37Aprovechar los debuggersSe menciona que los debuggers facilitan encontrar errores; se muestran más adelante en Visual Studio Code.
- 13:51Logear todoHacer print es lo básico, pero existen herramientas de logging que guardan en archivos o separan la salida de la terminal. Un presentador prefiere el debugger, salvo con datos grandes donde cada iteración es lenta; otro usa harto print. Se menciona gdb como herramienta antigua de debugging.
- 19:09Ubicar el problemaCuando el error no indica la línea, se usa búsqueda binaria sobre el código, con eficiencia logarítmica (unas 10 iteraciones para unas mil líneas). Ejemplos: duplicados por un full join, tipos de dato mal guardados, diferencias entre RStudio y la terminal, variables de entorno. También se mencionan errores dentro de librerías y la contribución a proyectos open source.
- 29:22Intentar replicar el errorHay que reproducir el problema con un ejemplo mínimo y aislado, lo que permite compartirlo en Stack Overflow u otras comunidades. En el medio hay una conversación sobre consejos para empezar en un trabajo nuevo (primeras impresiones, proactividad, ser honesto sobre lo que no se sabe).
- 36:23Preguntarle a la comunidadSi no hay forma de resolverlo, no hay que temer postear en Stack Overflow, tras buscar primero. A veces no hay resultados en Google porque el error fue propio, como una mala instalación.
- 37:43Probrar, probar y probarConviene hacer tests automáticos cuando el código crece y considerar test driven development. Los tests unitarios son esenciales en funciones o paquetes compartidos; en analítica el riesgo suele estar más en los datos, y se menciona la calidad de datos (data quality).
- 41:33Types y LintersLos editores subrayan variables no definidas, imports faltantes o código sin usar antes de ejecutar. Se discute cuándo preguntar a un senior: ni de inmediato ni nunca, con un balance. Se recomienda preguntar en un canal público del equipo y saber formular la pregunta con código reproducible.
- 48:38MemesSe comentan memes sobre buscar en Google, descansar para volver al problema y leer la documentación. También sobre usar prints y sobre bugs que terminan como features en los videojuegos. Se contesta una pregunta sobre usar ChatGPT para debuggear y se anuncia el aniversario de un año del canal con un stream especial. Además se avisa de los capítulos subidos (sobre código legible/reproducible/versionado y entrevistas de trabajo de data scientist).
- 56:41Demo y tips de debuggeo genéricos en VSCode para PythonTruco para ejecutar desde el inicio hasta la línea actual con Ctrl+Shift+Home y luego ejecutar la selección, válido en cualquier lenguaje interpretado. Con un dataset de películas se crea una función que transforma el score en categorías. Se muestra el uso de print con f-strings y su inconveniente: modifica el código y ensucia el control de versiones.
- 01:02:40Demo debuggerSe ponen breakpoints con expresión condicional, hit count y logpoint (el mensaje sale en la consola de debug, no mezclado con la salida). Se inicia con F5 y se explica la consola de debug, las variables locales y globales y los pasos con F10. Se ve que un error de `transform` aparece directamente en el debugger. También se discute si usar el mismo nombre de variable en el ámbito local y global.
- 01:14:45Cuándo NO ocupar el debugger y qué hacerCon datos grandes el debugger es lento porque ejecuta todo desde el comienzo. La alternativa es "desmembrar" la función a código plano en el ambiente global; hay discrepancias entre los presentadores. Otras alternativas: guardar un dataframe intermedio para cargarlo rápido. Se subraya que los errores más difíciles son los que no hacen caer el programa y se recomiendan chequeos visuales y preventivos de las variables, joins y transformaciones.
- 01:31:00CierreSe insiste en el debug preventivo para no llegar con números sin sentido a un gerente. Se agradece a la audiencia y termina el episodio.