Nella nostra azienda abbiamo una manciata di utenti R che hanno scritto collettivamente circa 30 script .R nell'ultimo anno. Gli script sono per lo più 100 righe o meno, che definiscono funzioni utili e riutilizzabili.
Al momento, il profilo utente di tutti contiene un codice che invia tutti i file in una directory "Common R Scripts" condivisa all'avvio.
Come trarremo vantaggio dalla scrittura di pacchetti R per sostituire questi script:
L' introduzione al R Packages spiega abbastanza bene i vantaggi:
In R, the fundamental unit of shareable code is the package. A package bundles together code, data, documentation, and tests, and is easy to share with others. As of January 2015, there were over 6,000 packages available on the Comprehensive R Archive Network, or CRAN, the public clearing house for R packages. This huge variety of packages is one of the reasons that R is so successful: the chances are that someone has already solved a problem that you’re working on, and you can benefit from their work by downloading their package.
Why write a package? One compelling reason is that you have code that you want to share with others. Bundling your code into a package makes it easy for other people to use it, because like you, they already know how to use packages. If your code is in a package, any R user can easily download it, install it and learn how to use it.
But packages are useful even if you never share your code. As Hilary Parker says in her introduction to packages: “Seriously, it doesn’t have to be about sharing your code (although that is an added benefit!). It is about saving yourself time.” Organising code in a package makes your life easier because packages come with conventions. For example, you put R code in R/, you put tests in tests/ and you put data in data/. These conventions are helpful because:
They save you time — you don’t need to think about the best way to organise a project, you can just follow a template.
Standardised conventions lead to standardised tools — if you buy into R’s package conventions, you get many tools for free.
It’s even possible to use packages to structure your data analyses, as Robert M Flight discusses in a series of blog posts.
Penso che la tua domanda non sia propriamente specifica per R, lo stesso problema si verifica spesso quando un gruppo di compagni di squadra ha del codice da condividere tra di loro, scritto in qualsiasi linguaggio di programmazione essi utilizzino. Con una quantità crescente di codice, raggiungono il punto in cui devono prendere in considerazione se continuano a condividerli lanciandoli liberamente in una cartella comune, o se utilizzeranno un meccanismo standard di packaging o libreria più rigido della lingua (almeno, per parti della base del codice).
La risposta a questa domanda è: "dipende" . L'utilizzo di meccanismi di packaging standard ha diversi vantaggi in merito a
forniscono uno standard per il controllo delle versioni e la gestione delle dipendenze
forniscono standard per la documentazione e la descrizione dell'API
trasferisci le dipendenze dal livello "per funzione" al "livello pacchetto", che riduce pesantemente il numero di dipendenze e le rende più gestibili
il meccanismo potrebbe fornire altri standard come la struttura del codice, i test, la documentazione, ecc.
Idealmente, questo dovrebbe rendere più facile per il team riutilizzare il codice.
D'altra parte, non lo ricevi mai gratis. Quando inizi a creare pacchetti, devi presentare un maintainer per ogni pacchetto, qualcuno che sta raccogliendo il codice sorgente per il pacchetto (e se necessario, apporta alcune modifiche editoriali), che decide cosa va lì dentro o cosa no, chi assegna un numero di versione al pacchetto e chi conosce approfonditamente il lato tecnico del meccanismo del pacchetto. Probabilmente il codice del pacchetto dovrà soddisfare un livello formale superiore di qualità rispetto al codice non confezionato (ad esempio, documenti e test aggiuntivi).
Quindi, se vuoi sapere se la tua squadra ha già raggiunto il punto in cui i benefici superano lo sforzo extra, non puoi semplicemente decidere questo confrontando gli script "30" e "60". Dipende dai fattori quante persone sono coinvolte nel tuo team nella scrittura e nella fornitura di script, da quanti li riutilizzano, quanto spesso avvengono cambiamenti, le persone nel tuo team hanno problemi nel trovare il codice esistente da riutilizzare, i problemi a capire come riutilizzare uno specifico funzione, problemi sulla risoluzione delle dipendenze e così via?
Quindi, se la tua squadra non ha problemi con l'approccio attuale, non fare nulla per ora. Se, tuttavia, vedi almeno alcuni dei problemi, ma non sei sicuro che la confezione li risolva, ti suggerisco di provarlo . Inserisci un po 'del codice corrente, il codice più riutilizzato in un pacchetto, pubblicalo nel tuo team e verifica se i benefici valgono il sovraccarico per il tuo team.
Dipende dagli script. Se funzionano come piccole applicazioni (un file * .R e alcuni file * .txt o * .csv su cui lavorare, tutto in un'unica directory) non è ovvio come trasformarli nel formato di un pacchetto. I pacchetti sono raccolte di strumenti di programmazione che aggiungono funzionalità agli script creati dagli utenti, mentre gli script sono strumenti per eseguire attività senza alcuna scrittura programmata (la copia e la modifica di file possono far parte del flusso di lavoro). Quindi, se il pubblico per la tua raccolta di sceneggiature non è tutto R-programmatori, devi certamente stare con il modulo di script. Quindi non si tratta di un numero crescente di script.
Leggi altre domande sui tag packages libraries configuration-management r