Algunos ejemplos de TDD para desarrollar las recetas del Makefile

02 Aug 2024 - Memo, Nepo y Mario

Descripción del problema

El Makefile del repo lambdas_aves_marinas tenía un objetivo que se modificaba a sí mismo. Esto hace que el objetivo siempre se tenga que generar aunque los ingredientes no se modificaron.
Con esto identificamos otros problemas derivados del uso incorrecto del Makefile y que podríamos cambiar para mejorar su uso.

Makefile muy largos vs. cortos. ¿Cómo podemos hacer el Makefile más cortos?
Definiciones de variables en el Makefile ¿Cuáles son sus ventajas y desventajas?
¿Qué ventajas y desventajas nos da el uso de abreviaturas como @, <, word, @F, @D?
Dos archivos de salida (objetivos) por una receta. Por ejemplo: reports/figures/mean_lambdas_per_taxon.png reports/tables/mean_lambdas_per_taxon_interval.csv:
Reescritura de archivos, un ejemplo lo podemos ver en la nota Blameless Postmortem: Incidente con el pico de la masa

Colocar un ingrediente por línea. Esto ayuda a la legibilidad para los humanos.
Los scripts que generemos tienen que tener una sola salida. Los futuros scripts tienen que seguir esta idea y separar los que identifiquemos que tengan dos salidas.
Sobre las abreviaturas, decidimos dejar algunas por convención $< y $@ siempre y cuando sea una receta corta con un solo ingrediente y objetivo. Evitamos el uso del resto de las abreviaturas.
Si la variable representa un solo archivo, usamos el nombre del archivo y no la variable.
Usamos variables solo cuando representan a más de un archivo.
Hay ocasiones que los archivos en una solo variable tiene diferente procesamiento. En estos casos preferimos dividir en dos variables. Por ejemplo, datos de islas que pasan por diferente flujo de análisis.
En las funciones “enlatadas” nos permiten obtener resultados que no irán en el reporte y solo definir los resultados que sí irán. Esto nos ayuda a no repetir código y hacer más corto el Makefile.

Abajo podemos ver algunos ejemplo de nuestros intentos.

Desarrollamos las funciones “enlatadas” sin necesidad de correr todo el reporte.
Aquí podremos encontrar un ejemplo del desarrollo de las funciones con TDD

Cada prueba corre todo el reporte. Consume mucho tiempo y recursos para reportes grandes (por ejemplo: lambdas_aves_marinas)