Quale metodologia software devo seguire quando eseguo ricerche?

Di solito analizzo i dati degli esperimenti e anche se ho uno schema generale di passaggi che devo fare, potrei aver bisogno di modificarli in base alle specifiche degli esperimenti o alle domande che stanno dietro. Di solito sono l'unica codifica.

Ho guardato Wikipedia, ma non sono sicuro di quale metodologia posso usare, in parte perché non ne ho mai seguito uno, e in parte perché a volte esploro solo i dati, per vedere come sono fatti, e altre volte voglio solo una risposta. (E poiché non mi aspetto molto di testare o avere una certa qualità sul mio codice)

Mi è stato chiesto di porre questa domanda dopo un'ora o due scoprendo che la funzione r tablesi basa sull'ordine dei vettori e non sul nome degli elementi con cui confrontarli. Quindi ho pensato di dover testare il comportamento e le funzioni in cui ho usato alcuni dati simulati. Ma ho usato la tabella dopo che altre analisi hanno portato alla mancanza di informazioni, quindi non avrei potuto seguire la metodologia di sviluppo basata sui test (se avessi capito bene). Tuttavia, ritengo che con un certo miglioramento nel modo in cui affronterò il progetto, potrei essere più efficiente, oltre a rilevare prima gli errori, ma anche come e cosa cercare nel caso in cui dubito di un risultato, quindi per favore non concentrarti solo su questo errore di esempio.

Quale metodologia software si adatta meglio alla ricerca?

In sostanza, sto chiedendo come garantire qualità e progressi a tempo, nonché mantenere la specificità della ricerca.

Esempio di come lavoro:

Un biologo ha in mente una domanda e sa che fare un esperimento porterà ad avere dati di interesse (cioè livelli di espressione genica in due condizioni), quindi imposta l'esperimento e raccoglie campioni da 10 persone / topi / ratti. Ora devo analizzare quei dati per quei 10 campioni usando le librerie e i test esistenti (o implementando nuovi test) ma tenendo conto della domanda che il biologo aveva in mente (cioè quali geni sono più espressi in una condizione che in un'altra). La struttura è la stessa dei precedenti esperimenti (che hanno coinvolto 6 condizioni e un altro animale) ma il test statistico, le normalizzazioni, la struttura dei dati possono cambiare. Quindi di solito copio una versione precedente e la adeguo alle esigenze attuali.

Ciò che è necessario non è forse una metodologia del software, ma un cambiamento politico nel mondo accademico che risolve il problema della mancanza di riconoscimento del ruolo svolto dallo sviluppo del software nella scienza.

Il Software Sustainability Institute (UK) è l'organizzazione più vicina a ciò che stai cercando: come discutere per un uso più coscienzioso della programmazione informatica nella ricerca scientifica.

Fornisce inoltre indicazioni per coloro che sono interessati alle metodologie di sviluppo del software.

Tuttavia, devo sottolineare che le metodologie in genere governano i team di programmatori di software, con iterazioni e perfezionamento graduale degli obiettivi del progetto, e lavora con basi di codice stabili che durano a lungo. Sono per progetti che sono ordini di grandezza più complessi di quello che stai facendo.

Per quanto riguarda il motivo per cui questa cosa molto evidentemente corretta (un uso più coscienzioso della programmazione informatica nella ricerca scientifica) non è stata compiuta e sempre sostenuta, ecco la scomoda verità: negli ambienti amministrativi accademici, gli scienziati possono vedere che degradano l'importanza giocata dal computer programmazione. A volte possono essere visti riunirsi per negare il riconoscimento dei contributi delle persone coinvolte nel software, anche se la natura di tale contributo rientra nella disciplina scientifica.

• http://www.scientific-computing.com/news/news_story.php?news_id=2737
• https://news.ycombinator.com/item?id=10553837

Sul posto di lavoro, ci sono cose che mancavano e cose che puoi fare.

Cose che mancavano:

• Mancanza di linee guida
• Mancanza di supervisione o persona per porre domande
• Mancanza di mentori o programmatori di computer che siano a conoscenza degli strumenti che usi (ad es. R)
• Mancanza di riutilizzo, archiviazione, controllo della versione o documentazione del software precedentemente sviluppato, a fini di ripetibilità e apprendimento

In breve, la cultura generale è che le persone coinvolte non sono veramente interessate a ... avete indovinato ... un uso più coscienzioso della programmazione informatica nella ricerca scientifica.

Cose che puoi fare:

• Dedica più tempo all'apprendimento dei tuoi strumenti.
  • Trascorri più tempo a leggere la documentazione e gli esempi di codice per i tuoi linguaggi di programmazione
  • Dovrai imparare ad amare gli strumenti che usi.
• Prova a scrivere qualcosa, a beneficio del prossimo programmatore di computer che sarà schiavizzato nello stesso gruppo di persone per i prossimi due anni
  • Una wiki sarà eccellente.
• Prova a impostare il controllo della versione di origine
  • Essere in grado di recuperare frammenti di codice comunemente riutilizzati
  • Essere in grado di salvare un'istantanea del codice utilizzato in un particolare esperimento

Per gli sviluppatori di software di carriera, linee guida di questo tipo sono disponibili in:

• Il test Joel: 12 passaggi per migliorare il codice di Joel Spolsky

Questi sono considerati i requisiti di base per gestire un'attività di sviluppo software. Tuttavia, quando stai combattendo una guerra di apatia, da solo, devi dare la priorità. Migliorare con gli strumenti, scrivere e conservare le informazioni, mantenere le versioni del codice sorgente è il minimo indispensabile per un unico ambiente.

Non preoccuparti troppo della metodologia, ma cerca di concentrarti di più su ciò di cui hai bisogno per tenere traccia, i tuoi requisiti, per lo sviluppo del software stesso.

Dopo aver fatto un breve soggiorno in una posizione relativamente simile alla tua qui è quello che posso estrarre dalla mia esperienza personale.

Esattezza algoritmica

Probabilmente l'aspetto più importante, dovresti essere in grado di dimostrare che il tuo software fa quello per cui è stato progettato. Qui i test automatici sono il tuo miglior alleato. Mi rendo conto che può essere difficile fare a meno di un set di dati adeguato, ma in realtà dovresti prendere l'abitudine di creare i tuoi set di dati. Il loro scopo è tuttavia leggermente diverso, non si sta tentando di estrarre la tendenza dai dati ma assicurarsi che il software produca risultati prevedibili e corretti da un set di dati noto. Quindi, ad esempio, per il riconoscimento dei pattern non è necessario un trucco genetico multi-concerto, bastano poche righe di testo per garantire che l'algoritmo rilevi il pattern.

Ero solito creare i miei dati per rappresentare casi angolari, casi impossibili. Tendevo a concentrarmi più sugli estremi che sulla norma attesa. Molte volte riesco a ricordare di aver testato qualcosa di impossibile solo per vedere sorgere questa situazione nel set di dati reale. Se non lo avessi testato, non avrei messo in atto i rilevamenti di errori e la registrazione necessari per identificare potenziali corruzioni o errori nel set di dati. TDD è adatto per questa parte, sebbene la creazione di un buon set di test sia più importante indipendentemente dal fatto che lo si faccia prima o dopo il codice effettivo.

versioning

Troppo spesso questa parte viene lasciata fuori. Un buon schema di versioning per il tuo codice e pacchetti / eseguibili prodotti ti aiuterà immensamente a mantenere i tuoi progressi in ordine. Essere in grado di recuperare esattamente il codice utilizzato per creare risultati precedentemente ottenuti può aiutare a rintracciare bug o discrepanze. La ramificazione può essere utile anche quando si sperimentano approcci o algoritmi diversi.

Assicurati di taggare il codice utilizzato nei calcoli effettivi, Controlla il controllo delle versioni semantico se hai bisogno di aiuto per nominare le versioni.

Build automatizzato

Un corollario al punto sopra. Assicurati di automatizzare il più possibile il processo di creazione e creazione del pacchetto del tuo software. Non è necessario diventare full monty, quanto basta per rendere banale la creazione del sistema finale dalla fonte e dalle dipendenze. L'obiettivo qui è farti risparmiare tempo ma anche avere un mezzo riproducibile per ricreare il software dalla fonte, comprese le dipendenze e altri elementi esterni. Groovy, Maven, ant, Scons, cmake, sono solo un piccolo esempio di strumenti di automazione della build e sistemi di scripting che possono aiutare.

Se vuoi fare il possibile, installa Jenkins o teamcity o qualsiasi altro sistema di integrazione continua. Aggiunto bonus se devi mantenere più server o lavoratori per il calcolo distribuito. La maggior parte di questi sistemi avrà i mezzi per aiutare nella manutenzione. Inoltre, sarai in grado di automatizzare completamente le esecuzioni di test in modo da non dover attendere i risultati prima di continuare, basta eseguire il commit e ricevere una mail in un secondo momento. Ho avuto un sistema che ha impiegato ore per superare i set di test. Mettere su questa automazione è stato il miglior investimento del mio tempo. Soprattutto se hai già gli script in atto per costruire tutto.

Isolamento dell'ambiente

I ricercatori trascorrono una quantità eccessiva di tempo a isolare un singolo o un piccolo insieme di variabili di interesse da sistemi complessi attraverso i loro protocolli. Questo dovrebbe essere esteso anche alle pratiche di sviluppo del software. Puoi anche verificare la containerizzazione con Docker o Vagrant. Ti darà un migliore controllo sull'ambiente in cui viene eseguito il software.

Non hai bisogno di avere una grande squadra prima che questo ripaghi, ero solo la maggior parte del tempo eppure ne ho beneficiato notevolmente mettendo in atto questi. La tranquillità e il tempo risparmiato ha fornito di gran lunga superiore al sovraccarico che mi è costato fare questo.

1. Puoi usare R? Ecco a cosa serve.

2. Mantieni il tuo codice semplice . Scegli la leggibilità e non preoccuparti delle prestazioni a meno che non sia un problema. Esistono metodologie per cercare di impedire ai team di programmatori di inserire bug nel codice reciproco, anche se il team è una persona.

3. Detto questo, la disciplina del codice è estremamente importante. Ho visto codice di scienziati e matematici avanzati altamente qualificati ed è terribile . Ignorano totalmente la formattazione. Compongono il codice come se fosse sottovuoto. I loro nomi di variabili sono totalmente mistificanti. Non scrivono commenti o scrivono commenti imperscrutabili, oppure i commenti dicono una cosa mentre il codice ne dice un'altra. Non fare quelle cose. Pensa sempre ai futuri cambiamenti che tu o gli altri potreste dover fare.