¿Cómo se combina "Control de revisión" con "Flujo de trabajo" para R?

Recuerdo encontrarme con usuarios de R que escriben que usan "Control de revisión" ( por ejemplo, "Control de fuente" ), y tengo curiosidad por saber: ¿Cómo combinas el "Control de revisión" con tu flujo de trabajo de análisis estadístico?

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

  • ¿Cómo organizar grandes progtwigs R?
  • Flujo de trabajo para el análisis estadístico y la networkingacción de informes

Una larga actualización de la pregunta : después de algunas de las respuestas de las personas 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 antes no estaba familiarizado), era claro para mí que al usar control de revisión, lo que uno hace es build una estructura de desarrollo de su código. Esta estructura conduce a un "producto final" o a varias twigs.

Al build algo como, digamos, un website. Generalmente hay un producto final para el que trabaja (el website), con algunos prototypes en el path.

Pero al hacer un análisis estadístico, el trabajo (a mi juicio) es diferente. A veces sabes a dónde quieres llegar. Pero más a menudo, exploras. Explore limpiar el set de datos. Explore diferentes methods para el análisis estadístico, y haga varias preguntas sobre sus datos (y estoy escribiendo esto, sabiendo cómo Frank Harrell y otros estadísticos de experiencia sienten sobre el dragado de datos ).

Es por eso que la pregunta del flujo de trabajo con progtwigció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 revisiones usa (y por qué)?
  • ¿Qué IDE usas (y por qué)? La pregunta más interesante es acerca del process de trabajo:
  • ¿Cómo estructuras tus files?
  • ¿Qué guarda como un file separado y qué es una revisión? o preguntando de otra manera: ¿qué debería ser una "sucursal" y qué debería ser un "subproyecto" en su código? Por ejemplo: cuando comience a explorar sus datos, ¿debería crearse una ttwig y luego borrarse porque no llevaba a ninguna parte (pero se mantuvo como una revisión) o debería haber un file de respaldo de esa ruta?

Cómo resolviste esta tensión fue mi curiosidad inicial. La segunda pregunta es "¿qué podría estar perdiendo?". ¿Qué reglas (de pulgar) debería seguir para evitar trampas comunes haciendo progtwigción estadística con control de versiones?

En mi intuición , creo que la progtwigción estadística es intrínsecamente diferente del desarrollo de software (estoy escribiendo esto sin ser un verdadero experto en progtwigción estadística, y mucho less en desarrollo de software). Es por eso que no estoy seguro de cuáles de las lecciones que he leído aquí sobre el control de versiones serían aplicables.

Muchas gracias, Tal

Mi flujo de trabajo no es tan diferente al de Bernd. Normalmente tengo un directory principal donde pongo todos mis files de código * .R. Tan pronto como tengo más de 5 líneas en un file de text, comienzo el control de la versión, en mi caso git. La mayor parte de mi trabajo no está en un context de equipo, lo que significa que soy el único que cambia mi código. Tan pronto como realice un cambio sustancial (sí, eso es subjetivo) hago un check in. Estoy de acuerdo con Dirk en que este process es ortogonal al flujo de trabajo.

Uso Eclipse + StatET y aunque hay un complemento 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 la idiosincrasia personal en el control de versiones, pero recomiendo este consejo como una mejor práctica: si informa los resultados a otros (es decir, artículo de revista, su equipo, administración en su empresa) SIEMPRE haga una verificación de control de versión en la derecha antes de ejecutar resultados que van a otros. Invariablemente, 3 meses después, alguien verá los resultados y hará alguna pregunta sobre el código que no podrá responder a less que conozca el estado EXACTO del código cuando produjo esos resultados. Así que conviértalo en una práctica y ponga los comentarios "esta es la versión del código que utilicé para las finanzas del 4to trimestre" o cualquiera que sea su caso de uso.

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

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

En lugar de centrarse en el control de revisiones en particular, parece que realmente se está haciendo una pregunta más grande 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 parecerse más a un arte que a una ciencia. En cierto sentido, es posible que desee search inspiración en el process que un autor seguiría al escribir un libro más que el process que un desarrollador de software seguiría. Por otro lado, todavía tengo que encontrarme con un proyecto de software que siguió una línea recta. E incluso a nivel teórico, existe una gran cantidad de variación en las metodologías de desarrollo de software . De estos, dado que un análisis estadístico puede ser un process de descubrimiento (es decir, uno que no se puede planificar completamente desde el principio), tendría sentido seguir algo así como una metodología ágil (mucho más para que algo así como la metodología de cascada). En otras palabras, debe planear 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 objective en mente es potencialmente problemático. Eso puede llevarte al punto en el que estás 5 pasos más allá de tu momento eureka, y no tienes forma de volver a él. Siempre hay un objective de algún tipo, incluso si el objective en sí está cambiando. Además, si no hay un objective, ¿cómo sabrá cuándo ha llegado al final?

Un enfoque es comenzar con un file R al comenzar un proyecto (o un set de files como los ejemplos de Josh y Bernd), y agregarlo progresivamente (para que crezca en tamaño) a medida que realiza descubrimientos. Esto también es especialmente cierto cuando tiene datos que deben mantenerse como parte del análisis. Este file debe tener una versión controlada regularmente para garantizar que siempre pueda retroceder si comete errores (lo que permite aumentos incrementales). Los sistemas de control de versiones son inmensamente útiles en el desarrollo, no solo porque garantizan que no pierdas cosas, sino también porque te proporcionan una línea de time. Y marque sus loggings para que sepa lo que hay en ellos de un vistazo, y tenga en count los principales hitos. Me encanta el punto de JD sobre el check-in antes de enviar algo.

Una vez que haya llegado a su set final de conclusiones, a menudo es mejor crear una versión final de su file que resum su análisis de principio a fin. Incluso podría considerar poner esto en un documento de Sweave para que sea totalmente autónomo y alfabetizado.

También debe pensar seriamente en lo que hacen otras personas a su alnetworkingedor. Nada me avergüenza más que ver a la gente reinventando la rueda, especialmente cuando significa trabajo adicional para que el grupo en su totalidad se integre.

Sus decisiones sobre qué sistema de control de versiones usar, qué IDE, etc. (problemas de implementación) son extremadamente bajos en el tótem en relación con la gestión general del proyecto. Simplemente use cualquiera de ellos correctamente y ya estará el 95% del path hasta allí, 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, código google o R-forge, notará algo que todos tienen en común: un set de herramientas más allá de un sistema de control de versiones. A saber, debe considerar usar cosas como el sistema de seguimiento de problemas y el wiki para documentar el progreso y registrar problemas / tareas abiertos. 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 directory típica (por ejemplo, para artículos) es la siguiente.

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

La mayoría de los directorys / files (ana, doc, org) están bajo control de versión. Por supuesto, los grandes sets de datos binarys están excluidos del control de versiones (a través de .gitignore). README es un file Emacs org-mode.

Después de leer su actualización, parece que está viendo la opción y el uso de un sistema de control de versiones como el que dicta la estructura de su repository 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 services:

  1. Copias de security Si algo se elimina accidentalmente o los caprichos del destino freirán tu disco duro, tu trabajo se podrá recuperar del repository. Con el control de versiones distribuidas, nada less que el apocalipsis puede hacer que pierdas el trabajo, en cuyo caso probablemente tengas otras cosas de las que preocuparte.

  2. La madre de todos los botones de deshacer. ¿El análisis se veía mejor hace una hora? ¿Hace un día? ¿Hace una semana? El control de versiones proporciona un button de rebobinado que le permite retroceder en el time.

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

La otra cara de los sistemas de control de versiones es que fomentan los esfuerzos de queueboración permitiendo que las personas experimenten en una copy aislada o "twig" del material del proyecto y luego "fusionen" cualquier cambio positivo de nuevo en la copy maestra. También proporciona un medio para que los miembros del proyecto controlen qué cambios afectaron qué líneas de qué files.

Como ejemplo, mantengo todos mis cursos universitarios bajo control de versiones en un repository de Subversion . Yo soy el único que trabaja en este repository, por lo que nunca ramifico o fusiono la fuente. Solo me comprometo y ocasionalmente rebobino. La capacidad de rebobinar mi trabajo networkinguce los riesgos de intentar algún tipo de análisis nuevo. Simplemente lo hago. Si dos horas después parece que no fue una buena idea, solo revertiré los files del proyecto e intentaré algo diferente.

Por el contrario, la mayoría de todo el desarrollo de mi package / progtwig sin cursos está alojado en git . En este tipo de configuration, con frecuencia quiero experimentar en una twig mientras tengo una copy maestra estable disponible. Utilizo git en lugar de Subversion en estas situaciones porque git hace que la bifurcación y la fusión sean una tarea fácil.

El punto importante es que, en ambos casos, la estructura de mi repository y el flujo de trabajo que utilizo no son decididos por mi sistema de control de versiones, los he decidido 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, decidir que no me gusta y luego tener que deshacer todos los cambios para volver al punto donde comencé. Como uso el control de versiones, puedo seguir el consejo de Yogi Berra:

Cuando llegas a una bifurcación en el path, tómalo.

Porque siempre puedo regresar y tomarlo de otra forma.

Yo uso git, yo mismo. Repositorios locales, almacenados en el mismo directory que el proyecto R. De esa forma, si elimino un proyecto en el futuro, el repository lo acompaña; Puedo trabajar sin connection; y no tengo asuntos de IRB, FERPA, HIPPA para tratar.

Si necesito una garantía de respaldo adicional, puedo acceder a un repository remoto (¡seguro!).

-Wil