E96 - Manifiesto de programación

Resumen

El episodio 96 presenta el "manifiesto de programación" de los anfitriones. Es un conjunto de buenas prácticas internas, creado hace unos 5 años, para ciencia de datos aplicada en empresas y equipos de trabajo, no en academia ni en desarrollo individual. Primero describen los valores que debe cumplir un buen código: resiliente y robusto, que facilite el traspaso, eficiente, agnóstico de herramientas y lenguajes, fácil de pasar a producción, alineado con una cultura común, con estructura pero flexible, que genere valor y que toma tiempo. Luego presentan las técnicas esenciales: estructura de carpetas con IDs en los scripts y outputs, nombres descriptivos, comentarios solo cuando explican el porqué, funciones y librerías reutilizadas, modularización, scripts en vez de notebooks, y dominio del IDE. Concluyen que la disciplina sostenida evita la entropía y la deuda técnica, que conviene estimar tiempos de forma realista (multiplicar por dos) y que los puntos son flexibles si hay un argumento detrás. También responden preguntas de la comunidad (estimación de proyectos, frecuencia de ejecución y reentrenamiento, cuándo usar machine learning) y muestran cómo ejecutar código línea a línea en VS Code sin notebooks.

Capítulos

• 00:00
  IntroPresentan el tema del episodio: un manifiesto interno de buenas prácticas de programación para ciencia de datos, creado hace unos 5 años y en evolución. Se aplica a Data Science empresarial y en equipo, no a academia, donde todo suele quedar en prueba de concepto.
• 00:31
  Qué es el manifiesto de programaciónSe divide en valores y en técnicas (esenciales, intermedias y avanzadas). Mientras más reglas se piden, más difícil es la adherencia. Sin disciplina aumenta la entropía: caos en proyectos y validaciones, más horas de trabajo y código que se desecha. Aplicarlo con equipos de unas 40 personas que rotan es un desafío, y los seniors tienden a resistirse más.
• 06:19
  ValoresEnumeran los valores: código resiliente y robusto, que facilite el traspaso y la continuidad, eficiente, que permita distintas herramientas y lenguajes, de paso sencillo a producción, de cultura común, con estructura flexible, que genere valor y que toma tiempo.
• 07:25
  Un buen código es resiliente y robustoDebe poder ejecutarse en otra máquina y ser reproducible. Si no, no sirve al pasárselo a otra persona.
• 08:09
  Un buen código facilita el traspaso y la continuidadSeguir una base metodológica común permite que otros lean, continúen y pongan en producción tu trabajo. Ejemplo: un externo entregó código en pedazos por correo, difícil de entender y sin reproducir el mismo resultado.
• 09:57
  Un buen código es eficienteLa eficiencia puede entenderse en tiempo, legibilidad o recursos. Los valores son "mandamientos" que cada equipo adapta a su contexto.
• 10:37
  Un buen código permite ocupar distintas herramientas y lenguaje de programaciónUsar un solo lenguaje por apego es perder oportunidades. Las herramientas (lenguaje, base de datos, framework) deben elegirse con criterio y no por moda.
• 12:43
  Un buen código permite un sencillo paso a producciónLa parametrización es clave para ejecutar con distintos meses, semanas o inputs. Hay que empezar a parametrizar en cuanto el proyecto va bien encaminado, para no tener que rehacer un código "espagueti" al final.
• 14:10
  Un buen código pertenece a una cultura en comúnLo comparan con el manifiesto ágil: es útil por su generalidad, y sus implementaciones (Scrum, Extreme Programming) sirven en unos contextos y en otros no. Las prácticas dependen de si el equipo trabaja de forma individual o en grupo, con integración continua.
• 15:15
  Un buen código sigue una estructura que, a la vez, es flexibleSe necesita una base fija para hablar un lenguaje común, pero imponerla de forma estricta es complicado de controlar. Se permite adaptarla con análisis y argumentos, por ejemplo creando una carpeta nueva para probar una herramienta.
• 17:10
  Un buen código genera valor a la empresaSi el código no genera valor (dinero, ahorro, bienestar o conocimiento), es mejor no hacerlo. Un equipo de investigación también cuenta como "empresa" por apuntar a un objetivo.
• 18:03
  Un buen código toma tiempoHay que aprender a decir "no alcanzo en una semana" y estimar de forma realista. Dejar pequeñeces para después acumula deuda técnica, que obliga a borrar todo y empezar de cero. Recomiendan multiplicar la estimación por dos. Aclaran que el manifiesto completo aún no es público y que compartirán una versión agnóstica en un repositorio vía Discord.
• 23:14
  Buenas prácticas de programación para lograr todo estoSe priorizan las prácticas con más aporte y menor esfuerzo, en tres niveles: esenciales, intermedias y avanzadas.
• 24:15
  Usar una estructura de carpetas y scriptsEstructura base de carpetas parecida a Cookiecutter, pero sin carpeta `source` para reducir la profundidad. Hay carpetas como pipeline, models, execution, reportes y `files` (para datasets, modelos, outputs y logs). Cada script lleva un ID de una letra más dos dígitos (por ejemplo `a01`), que sirve para buscarlo rápido y ordenar la ejecución. Los outputs heredan el ID del script como prefijo, junto con fecha o parámetros. Mencionan Snakemake para flujos tipo DAG, que evita que un script fallido deje un archivo antiguo con nombre estático. Si los nombres se generan a mano, recomiendan una función que los automatice.
• 35:40
  MemesExplican la estructura del stream. Anuncian un meetup presencial de ciencia de datos en Santiago de Chile, con Daniel Fiter y otros, abierto a expositores. Revisan memes sobre IA generando videos de gimnasia artística, regresión lineal aplicada a todo, refactorizar al final del desarrollo y dudas al pasar a producción con código espagueti.
• 43:32
  Respondiendo preguntas de discordResponden cuatro preguntas. Para estimar tiempos, descomponer el proyecto en etapas pequeñas (datos, comprensión, implementación, mlops) y multiplicar por dos. La frecuencia de ejecución depende del objetivo, y el reentrenamiento se decide al observar el desgaste de las métricas. Para decidir si usar machine learning, primero se define el problema. Los episodios se subirán los jueves a las 11:00. Mencionan Positron, el IDE de la empresa creadora de Quarto, que es un fork de VS Code orientado a ciencia de datos y aún está en beta.
• 57:01
  Usar nombres descriptivos para las variablesLos nombres deben entenderse al leerlos. Evitar letras sueltas como `i`, `e` o `df`, y preferir snake_case o camelCase de forma consistente. Para funciones usar verbos (`obtener_facturacion_cliente`, `calcular_impuestos`). Con datos pequeños (menos de 1 GB) conviene guardar checkpoints con nombres como `alarmas_raw` o `alarmas_sin_outliers` para depurar más rápido. Sobre el idioma, lo importante es ser consistente según el equipo.
• 01:05:44
  Comentar los códigosHay dos escuelas extremas: no comentar nada o comentarlo todo. El anfitrión se inclina por pocos comentarios, salvo los que explican el porqué de una decisión no intuitiva. Son útiles los comentarios de sección, los TODO y los warnings, con la extensión Better Comments de VS Code. Advierten que el código generado por GPT suele venir sobrecomentado y que los comentarios se desactualizan.
• 01:12:35
  Hacer buen uso de las funciones / Usar librerías preexistentesSi algo se repite más de dos veces, conviene hacer una función. Si una librería confiable ya la ofrece, mejor usarla. Evitar duplicidad previene inconsistencias al modificar.
• 01:13:50
  Modularizar los proyectosDividir en módulos por tarea (lectura y formatos, nulos y duplicados, escalamiento) facilita localizar errores. Se reutiliza el preproceso común entre entrenamiento y evaluación, y se deja aparte lo específico, como el escalamiento, para evitar data leakage. El logging se considera seguimiento del proceso y no documentación.
• 01:18:54
  Saber cuándo ocupar scripts o notebooksEl manifiesto se aplica a scripts, no a Jupyter Notebooks. Recomiendan Quarto para reportes por ser más reproducible. Critican que los notebooks fomentan malas prácticas, dificultan la productivización y llenan de output. Reconocen que pueden servir a alguien no técnico que quiere una interfaz amigable.
• 01:24:03
  Conocer los distintos usos de los "Integrated development environment" (IDE)Hay que elegir un IDE y dominar sus atajos, configuración e integraciones. Características deseables: autocompletado, ejecución línea a línea, shortcuts propios, cambio rápido de pestaña, comentar bloques y visualización de gráficos. Recomiendan RStudio, VS Code para algunas cosas, terminal con tmux y SQL Developer para SQL.
• 01:26:43
  Resumen de Técnicas básicas y avanzadasListan sin detallar: no usar cadenas de operaciones largas, no sobrescribir variables en datasets pequeños, formatos eficientes (rds, feather, parquet en vez de CSV), backup y revisión por un compañero, estructura de carpetas poco profunda, ambientes virtuales y variables de ambiente para contraseñas, parametrizar scripts (por ejemplo con JSON), nombres de output automáticos, linter y formateador automático.
• 01:29:06
  Duda: Cómo ejecutar código línea a líneaDemuestran en VS Code cómo enviar a la terminal una línea, una selección o una instrucción multilínea con Ctrl+Enter (por defecto Shift+Enter), tanto en Python como en R y Bash. Es más flexible que las celdas de Jupyter. Mencionan un tema de VS Code (Dracula) y avisan que una extensión maliciosa de tema oscuro tenía un virus.
• 01:34:23
  CierreRecuerdan el canal de Discord y los episodios pasados en YouTube sobre notebooks, Quarto y Git. Aclaran que ejecutar con el comando envía la línea completa o el bloque hasta cerrar el paréntesis. Se despiden pidiendo like y suscripción.

Palabras clave