Spara de olika skripten med git (verkar överdrivet)

Whoa. Jag gjorde en faktisk dubbeltagning när jag läste det här: ¹ det är motsatsen av överkill.

Version som styr dina skript (med Git eller något liknande) är absolut minimum och bör bli helt automatisk. För varje nytt projekt jag börjar är ett av de allra första stegen att utfärda kommandot git init och att skapa ett fjärrlagringsförvar (på Github).

Att hålla koll av olika analyser använder jag en kombination av följande tillvägagångssätt:

1. Skriv återanvändbara funktioner / skript och parametrisera. Parametrarna förvaras antingen inuti själva skriptet (som sedan anropar relevant funktion upprepade gånger) eller i en Makefile (jag rekommenderar Snakemake).
2. Dokumentera de alternativa analysmetoderna; återigen kan det här vara en Makefile med olika regler för alternativa analyser, eller en uppsättning anteckningsböcker (via R Markdown).
3. Har olika Git-grenar för ömsesidigt exklusiva metoder. I slutet av analysen slås en av dessa grenar samman till master och publiceras. Om jag vill publicera flera analysmetoder slår jag samman alla dessa grenar till master och använder metoder (1) eller (2) för att aktivera dem samtidigt.

I Jag rekommenderar faktiskt att skapa en Makefile för varje analys; Jag har funnit att detta är det mest praktiska, självdokumenterande sättet att köra en analys. Det liknar närmast en bärbar dator för lab-lab. Fördelen med ett enda R Markdown-dokument är att körning av bara delar av analysen kan automatiseras helt och beroenden i arbetsflödet framgår av beroenden i Makefile-reglerna. Det här är mycket svårare i R Markdown.

För en tid sedan skapade jag ett exempel på arbetsflöde för analys för att visa hur detta kan struktureras. Numera skulle jag använda Snakemake istället för GNU make.

När det gäller din andra punkt:

Gör anteckningar i själva skriptet

"Anteckningar" är ett farligt djur: dokumentation är viktigt, men erfarenheten visar att det ibland är mycket svårt att hålla dokumentation synkroniserad med koden. Det finns ingen mekanism som säkerställer att dokumentation och kod faktiskt överensstämmer. Skillnader mellan antagen analys och faktiskt utförd analys kan bli mycket problematiska.

Människor föredrar därför att använda självdokumenterande kod så mycket som möjligt; det vill säga: att skriva kod så att dess betydelse blir omedelbart tydlig, utan kommentarer, även till någon som inte har arbetat med koden tidigare. Att göra det här är svårt och kräver övning, men förbättrar den totala kodkvaliteten. Återigen hjälper det här att använda en Makefile eftersom beroenden mellan reglerna självdokumenterar vilken typ av analys som utfördes.

Jeff Atwood har skrivit två grundläggande uppsatser om detta ämne:

• Kodning utan kommentarer och
• Koden berättar hur, kommentarer berättar varför.

De är två av de bästa råd om programmering som jag kan ge.

¹ För att betona: ta en titt på redigeringshistoriken av detta svar.

Huvudsyftet med git är att versionskod, vilket vanligtvis betyder sekventiell förbättring av kodbasen. Även om det är möjligt att använda filialer för flera varianter av programvaran används permanenta filialer traditionellt för gradvis integration av nya funktioner (dvs. dev / test / mastergrenar). För att stödja flera oberoende filialer krävs en del investeringar, dvs. distribution av vanliga förändringar mellan filialer via sammanslagning eller körsbärsplockning. Detta är svårt att hantera när du har mer än två-tre grenar.

Om du jämför olika analysmetoder vill du förmodligen jämföra resultaten mellan metoderna. Att ha dem på separata grenar gör det svårt.

Enligt min mening bör du integrera alla analysmetoder i huvudgrenen. För att undvika kopiering av &-klistra är det bättre att placera vanlig kod i ett bibliotek eller ett oberoende skript. Du kan också ange en metod som en körningsparameter för din pipeline och skapa ett metaskript som kommer att utföra alla intressanta metoder.

När du har utfört benchmarking bör du inte ta bort oanvända metoder från du behärskar filialen. Att ha dem är viktigt för reproducerbar forskning, och dina skript kan användas i framtiden för nya datamängder.

Jag håller helt med detta svar av @Konrad Rudolph.

Jag vill betona att det är det som hjälper dig att undvika att multiplicera grenar i git genom att använda parametrisering för dina skript. Så ja, använd git, men du behöver inte nödvändigtvis "överdriva" för att skapa massor av grenar.

Sedan skulle jag beordra dessa skript från ett arbetsflödeshanteringsverktyg som på något sätt tar hand om att generera grenar av dina analyser. Om du använder Snakemake representeras de olika alternativen längs sökvägen från dina data till dina resultat av jokersystemet, och detta kommer att synas i strukturen för dina mappar och filnamn, på grund av att Snakemake fungerar genom att dra slutsatser vad ska göras för att producera en fil baserat på dess namn.

Detta är naturligtvis inte en ursäkt för att inte använda andra dokumentationsmetoder: Kommentarer i Snakefile och i skript, README-filer som förklarar hur arbetsflödet var kör, med vilken konfigurationsfil. Sätt dina skript, Snakefile, dess konfigurationsfiler och README-filer under versionskontroll och dokumentera igen med hjälp av kommunicera meddelanden.