version control - ¿Cómo combina “Control de revisión” con “Flujo de trabajo” para R?

version-control workflow (5)

Después de leer su actualización, parece que está viendo la elección y el uso de los sistemas de control de versión como dictados de la estructura de su repositorio y flujo de trabajo . En mi opinión, el control de versiones es más parecido a una póliza de seguro, ya que proporciona los siguientes servicios:

Copias de seguridad. Si algo se borra accidentalmente o los caprichos del destino fríen su disco duro, su trabajo puede recuperarse del repositorio. Con el control de versiones distribuido, nada menos que el apocalipsis puede hacer que pierda el trabajo, en cuyo caso probablemente tenga otras cosas de las que preocuparse.
La madre de todos los botones deshacer. ¿El análisis se veía mejor hace una hora? ¿Hace un día? ¿Hace una semana? El control de versiones proporciona un botón de rebobinado que le permite viajar en el tiempo.

Si usted es la única persona que trabaja en un proyecto, los dos puntos anteriores probablemente describen cómo los sistemas de control de versiones afectarán la forma en que trabaja.

La otra parte de los sistemas de control de versiones es que fomentan los esfuerzos de colaboración al permitir que las personas experimenten en una copia aislada o "rama" del material del proyecto y luego "fusionen" cualquier cambio positivo en la copia maestra. También proporciona un medio para que los miembros del proyecto mantengan un registro de quiénes cambios afectaron a qué líneas de qué archivos.

Como ejemplo, mantengo todos mis cursos universitarios bajo el control de versiones en un repositorio de Subversion . Soy el único que trabaja en este repositorio, por lo que nunca bifurco ni fusiono la fuente, solo me comprometo y ocasionalmente rebobino. La capacidad de rebobinar mi trabajo reduce los riesgos de probar algún tipo de nuevo análisis: simplemente lo hago. Si dos horas después parece que no fue una buena idea, simplemente revierto los archivos del proyecto e intento algo diferente.

En contraste, la mayor parte de mi desarrollo de paquete / programa que no es de curso está alojado en git . En este tipo de configuración, con frecuencia quiero experimentar en una rama mientras tengo una copia maestra estable disponible. Uso git en lugar de Subversion en estas situaciones porque git hace que la ramificación y la fusión sean una tarea sin esfuerzo.

El punto importante es que en ambos casos, la estructura de mi repositorio y el flujo de trabajo que utilizo no están decididos por mi sistema de control de versiones, sino que los decido yo. El único impacto que tiene el control de versiones en mi flujo de trabajo es que me libera de preocuparme por probar algo nuevo, decidiendo que no me gusta y luego tener que deshacer todos los cambios para volver al punto de partida. Como uso el control de versiones, puedo seguir el consejo de Yogi Berra:

Cuando llegues a una bifurcación en el camino, tómala.

Porque siempre puedo volver y tomarlo a la inversa.

Recuerdo que me encontré con usuarios de R que escribieron que usan "Control de revisión" ( por ejemplo: "Control de fuente" ), y tengo curiosidad por saber: ¿Cómo combina "Control de revisión" con su flujo de trabajo de análisis estadístico?

Dos (muy) discusiones interesantes hablan sobre cómo tratar con el flujo de trabajo. Pero ninguno de ellos se refiere al elemento de control de revisión:

Una actualización larga de la pregunta : Siguiendo algunas de las respuestas de la gente y la pregunta de Dirk en el comentario, me gustaría dirigir mi pregunta un poco más.

Después de leer el artículo de Wiki sobre " control de revisión " (con el que anteriormente no estaba familiarizado), me quedó claro que al usar el control de revisión, lo que uno hace es construir una estructura de desarrollo de su código. Esta estructura conduce a un "producto final" o a varias ramas.

Al construir algo como, digamos, un sitio web. Normalmente hay un producto final para el que trabaja (el sitio web), con algunos prototipos en el camino.

Pero al hacer un análisis estadístico, el trabajo (a mi modo de ver) es diferente. A veces sabes a dónde quieres llegar. Pero más a menudo, usted explora. Explora la limpieza del conjunto de datos. Explore diferentes métodos para el análisis estadístico y haga varias preguntas sobre sus datos (y estoy escribiendo esto, sabiendo cómo se siente Frank Harrell y otros estadísticos de la experiencia sobre el dragado de datos ).

Es por eso que la pregunta del flujo de trabajo con la programación estadística es (en mi opinión) una pregunta seria y profunda, que plantea muchos problemas. Los más simples son técnicos:

¿Qué software de control de revisión utilizas (y por qué)?
¿Qué IDE usas (y por qué)? Las preguntas más interesantes son sobre el proceso de trabajo:
¿Cómo estructuran sus archivos?
¿Qué guardas como un archivo separado y qué como una revisión? o preguntar de otra manera: ¿Qué debería ser una "sucursal" y qué debería ser un "subproyecto" en su código? Por ejemplo: al comenzar a explorar sus datos, ¿debería crearse un gráfico y luego borrarse porque no llevó a ninguna parte (pero se mantuvo como una revisión) o debería haber un archivo de copia de seguridad de esa ruta?

Cómo resolver esta tensión fue mi curiosidad inicial. La segunda pregunta es "¿Qué podría faltar?". ¿Qué reglas (de oro) se deben seguir para evitar las trampas comunes de la programación estadística con el control de versiones?

En mi intuición , siento que la programación estadística es intrínsecamente diferente al desarrollo de software (estoy escribiendo esto sin ser un verdadero experto en programación estadística, y mucho menos en el desarrollo de software). De esa manera no estoy seguro de cuál de las lecciones que he leído aquí sobre el control de versiones sería aplicable.

Muchas gracias tal

En lugar de centrarse en el control de revisión en particular, parece que realmente está haciendo una pregunta más amplia sobre cómo se compara el análisis estadístico con el desarrollo de software. Esa es una pregunta interesante. Aquí hay algunos pensamientos:

El análisis de datos puede ser más como un arte que una ciencia. En cierto sentido, es posible que desee buscar inspiración en el proceso que un autor seguiría al escribir un libro más que el proceso que seguiría un desarrollador de software. Por otro lado, todavía tengo que encontrar un proyecto de software que sigue una línea recta. E incluso a nivel teórico, existe una gran variación en las metodologías de desarrollo de software . De estos, dado que un análisis estadístico puede ser un proceso de descubrimiento (es decir, uno que no puede planificarse completamente por adelantado), tendría sentido seguir algo como una metodología ágil (mucho más que algo como la metodología de la cascada). En otras palabras, necesita planificar para que su análisis sea iterativo y autorreflexivo.

Dicho esto, creo que la noción de que el análisis estadístico es puramente exploratorio sin un objetivo en mente es potencialmente problemática. Esto puede llevar al punto en el que se encuentra 5 pasos más allá de su momento eureka y no tiene forma de volver a él. Siempre hay un objetivo de algún tipo, incluso si el objetivo mismo está cambiando. Además, si no hay un objetivo, ¿cómo sabrás cuando hayas llegado al final?

Un enfoque es comenzar con un archivo R al iniciar un proyecto (o un conjunto de archivos como en los ejemplos de Josh y Bernd), y agregarlo progresivamente (para que crezca de tamaño) a medida que realiza descubrimientos. Esto también es especialmente cierto cuando tiene datos que deben conservarse como parte del análisis. Este archivo debe controlarse la versión con regularidad para garantizar que siempre pueda retroceder si comete errores (lo que permite ganancias incrementales). Los sistemas de control de versiones son de gran ayuda en el desarrollo, no solo porque garantizan que no pierdas nada, sino también porque te proporcionan una línea de tiempo. Y etiquete sus registros para que sepa lo que hay en ellos de un vistazo, y observe los hitos principales. Me encanta el punto de JD sobre el registro antes de enviar algo.

Una vez que haya alcanzado su conjunto final de conclusiones, a menudo es mejor crear una versión final de su archivo que resuma su análisis de principio a fin. Incluso podrías considerar poner esto en un documento de Sweave para que sea completamente autónomo y letrado.

También debes pensar seriamente en lo que los demás a tu alrededor están haciendo. Nada me hace temblar más que ver a las personas reinventando la rueda, especialmente cuando se trata de trabajo adicional para que el grupo en general se integre.

Sus decisiones sobre qué sistema de control de versión usar, qué IDE, etc. (problemas de implementación) son, en última instancia, extremadamente bajas en el tótem en relación con la gestión general del proyecto. Simplemente use cualquiera de ellos correctamente y ya está en el 95% del camino, y las diferencias entre ellos son pequeñas en comparación con la alternativa de no usar nada.

Por último, si está utilizando algo como github, google code o R-forge, notará algo que todos tienen en común: un conjunto de herramientas más allá de un sistema de control de versiones. Es decir, debe considerar el uso de elementos como el sistema de seguimiento de problemas y la wiki para documentar el progreso y registrar problemas / tareas abiertas. Cuanto más organizado esté con su análisis, mayor será la probabilidad de éxito.

Estoy usando git para el control de versiones. Mi estructura de directorio típica (por ejemplo, para artículos) es la siguiente.

. .. .git README README.html ana dat doc org

La mayoría de los directorios / archivos (ana, doc, org) están bajo control de versión. Por supuesto, los grandes conjuntos de datos binarios están excluidos del control de versiones (a través de .gitignore). README es un archivo de modo org de Emacs.

Mi flujo de trabajo no es tan diferente al de Bernd. Por lo general, tengo un directorio principal donde coloco todos mis archivos de código * .R. Tan pronto como tengo más de aproximadamente 5 líneas en un archivo de texto, comienzo el control de versiones, en mi caso git. La mayor parte de mi trabajo no está en un contexto de equipo, lo que significa que soy el único que cambia mi código. Tan pronto como hago un cambio sustancial (sí, eso es subjetivo) hago un chequeo. Estoy de acuerdo con Dirk en que este proceso es ortogonal al flujo de trabajo.

Utilizo Eclipse + StatET y aunque hay un plugin para git en Eclipse ( EGit y probablemente otros), no lo uso. Estoy en Windows y solo uso git-gui para Windows. Aquí hay algunas opciones más .

Hay mucho espacio para idiosincrasias personales en el control de versiones, pero recomiendo este consejo como una buena práctica: si informa los resultados a otros (es decir, un artículo de una revista, su equipo, la administración de su empresa) SIEMPRE realice una verificación de control de versiones Antes de ejecutar resultados que salen a los demás. Invariablemente, 3 meses después, alguien verá sus resultados y hará algunas preguntas sobre el código que no podrá responder a menos que sepa el estado EXACTO del código cuando produjo esos resultados. Así que conviértalo en una práctica y ponga en los comentarios "esta es la versión del código que usé para las finanzas del cuarto trimestre" o cualquiera que sea su caso de uso.

También tenga en cuenta que el control de versiones no reemplaza un buen plan de respaldo. Mi lema es: "3 copias. 2 geografías. 1 mente en paz".

EDITAR (24 de febrero de 2010): Joel Spolsky, uno de los fundadores de , acaba de lanzar una introducción muy visual y muy interesante para Mercurial . Este tutorial solo puede ser una razón para adoptar Mercurial si aún no ha elegido un sistema de control de revisión. Creo que cuando se trata de Git vs. Mercurial, el consejo más importante es elegir uno y usarlo. Tal vez use lo que sus amigos / compañeros de trabajo usen o use el que tiene el mejor tutorial. ¡Pero solo usa uno ya! ;)

Yo uso git, yo mismo. Repositorios locales, almacenados en el mismo directorio que el proyecto R. De esa manera, si elimino un proyecto en el futuro, el repositorio lo acompaña; Puedo trabajar fuera de línea; y no tengo problemas con IRB, FERPA, HIPPA para tratar.

Si necesito una garantía de copia de seguridad adicional, puedo acceder a un repositorio remoto (¡asegurado!).

-Wil