Guarde los diferentes scripts con git (parece excesivo)

Vaya. Hice una doble toma al leer esto: ¹ es el opuesto de overkill.

La versión que controla sus scripts (usando Git o algo similar) es el mínimo absoluto, y debería volverse completamente automático. Para cada nuevo proyecto que comienzo, uno de los primeros pasos es emitir el comando git init y configurar un repositorio remoto (en Github).

Para realizar un seguimiento de análisis diferentes, utilizo una combinación de los siguientes enfoques:

1. Escribir funciones / scripts reutilizables y parametrizar. Los parámetros se mantienen dentro del propio script (que luego llama repetidamente a la función relevante) o en un Makefile (recomiendo Snakemake).
2. Documente los enfoques de análisis alternativos; una vez más, esto podría ser un Makefile con diferentes reglas para análisis alternativos, o un conjunto de cuadernos (vía R Markdown).
3. Tener diferentes ramas de Git para enfoques mutuamente excluyentes. Al final del análisis, una de estas ramas se fusiona en master y se publica. Si quiero publicar varios enfoques de análisis, fusiono todas estas ramas en master y uso los enfoques (1) o (2) los habilito simultáneamente.

En de hecho, recomiendo crear un Makefile para cada análisis; He descubierto que esta es la forma más práctica y autodocumentada de ejecutar un análisis. Se parece más a un cuaderno de laboratorio de laboratorio húmedo. La ventaja sobre un solo documento de R Markdown es que volver a ejecutar solo partes del análisis puede automatizarse por completo, y las dependencias en el flujo de trabajo son evidentes a partir de las dependencias de las reglas de Makefile. Esto es mucho más difícil en R Markdown.

Hace algún tiempo creé un flujo de trabajo de análisis de ejemplo para mostrar cómo se puede estructurar. Hoy en día usaría Snakemake en lugar de GNU make.

En cuanto a su otro punto:

Tome notas en el propio script

Las "notas" son bestias peligrosas: la documentación es importante, pero la experiencia muestra que a veces es muy difícil mantener la documentación sincronizada con el código. No existe ningún mecanismo que garantice que la documentación y el código coincidan. Las diferencias entre el análisis presunto y el análisis realmente ejecutado pueden volverse muy problemáticas.

Por lo tanto, la gente prefiere usar código autodocumentado tanto como sea posible; es decir: escribir código para que su significado sea inmediatamente claro, sin comentarios, incluso para alguien que no haya trabajado antes en el código. Hacer esto bien es difícil y requiere práctica, pero mejora la calidad general del código. Una vez más, usar un Makefile ayuda aquí porque las dependencias entre las reglas autodocumentan el tipo de análisis que se realizó.

Jeff Atwood ha escrito dos ensayos fundamentales sobre este tema:

• Codificación sin comentarios y
• El código le dice cómo, los comentarios le dicen por qué.

Son dos de los mejores consejos sobre programación que puedo dar.

¹ Para enfatizar: echa un vistazo al historial de ediciones de esta respuesta.

El propósito principal de git es la versión del código, lo que generalmente significa una mejora secuencial del código base. Si bien es posible utilizar ramas para múltiples variantes del software, las ramas permanentes se utilizan tradicionalmente para la integración gradual de nuevas funciones (es decir, ramas dev / testing / master). El soporte de múltiples sucursales independientes requiere cierta inversión, es decir, distribuir cambios comunes entre sucursales mediante fusión o selección selectiva. Esto es difícil de manejar cuando tiene más de dos o tres ramas.

Si compara diferentes métodos de análisis, probablemente desee comparar los resultados entre métodos. Tenerlos en ramas separadas dificulta las cosas.

En mi opinión, debería integrar todos los métodos de análisis en la rama maestra. Para evitar copiar & paste, es mejor poner el código común en una biblioteca o un script independiente. También puede especificar un método como parámetro de tiempo de ejecución de su canalización y crear un meta-script que ejecutará todos los métodos de interés.

Una vez que haya realizado la evaluación comparativa, no debe eliminar los métodos no utilizados de usted domina la rama. Tenerlos es importante para una investigación reproducible y sus scripts podrían usarse en el futuro para nuevos conjuntos de datos.

Estoy bastante de acuerdo con esta respuesta de @Konrad Rudolph.

Me gustaría enfatizar que usar la parametrización para sus scripts es lo que le ayudará a evitar multiplicar ramas en git. Entonces, sí, use git, pero no necesariamente tiene que "exagerar" creando muchas ramas.

Luego, ordenaría estos scripts desde una herramienta de administración de flujo de trabajo que de alguna manera se encargará de generar el ramas de sus análisis. Si usa Snakemake, las diversas opciones tomadas a lo largo de la ruta de sus datos a sus resultados estarán representadas por el sistema de comodines, y esto será visible en la estructura de sus carpetas y nombres de archivos, debido al hecho de que Snakemake funciona al inferir qué se debe hacer para producir un archivo basado en su nombre.

Esto, por supuesto, no es una excusa para no usar otros enfoques de documentación: comentarios en el Snakefile y en los scripts, archivos README que explican cómo fue el flujo de trabajo ejecutar, usando qué archivo de configuración. Ponga sus scripts, el Snakefile, sus archivos de configuración y los archivos README bajo control de versiones y documente nuevamente usando mensajes de confirmación.