Riferimenti citabili per le migliori pratiche di software

Attualmente sto scrivendo la mia tesi di dottorato. Ho speso una parte significativa del mio dottorato di ricerca per ripulire ed estendere il codice scientifico esistente, applicando le migliori pratiche di ingegneria del software che non erano state precedentemente utilizzate e vorrei scriverne nella mia tesi. Piuttosto che semplicemente dire "Ho aggiunto unit test", voglio essere in grado di scrivere qualcosa del genere:

J. Doe ha inventato i test unitari nel 1975 [ 23 ] . Un recente studio di Bloggs et al [ 24 ] ha mostrato che i test unitari riducono l'incidenza di errori del software del 73% ... 234 test unitari separati sono stati aggiunti alla base di codice, gestiti dal framework xUnit creato da Timpkins et al [ 25 ]$^{[23]}$$^{[24]}$$^{[25]}$

Sto cercando riferimenti accademici citabili (preferibilmente articoli su riviste peer-reviewed dove posso ottenere DOI, BibTeX ecc.) Alle migliori pratiche di ingegneria del software ampiamente accettate, in particolare:

• test unitari
• controllo della versione
• modularizzazione / separazione delle preoccupazioni
• profilazione / ottimizzazione delle prestazioni basata su informazioni di profilazione
• tracciamento bug / problem

Sto cercando informazioni sia sull'invenzione iniziale sia sulle successive valutazioni di efficacia. Se c'è un articolo di recensione che elenca tutte queste cose in un unico posto, tanto meglio.

Il libro Code Complete, 2a edizione di Steve McConnell ha un'ampia bibliografia che discute di questi problemi dal punto di vista degli sviluppatori software piuttosto che degli scienziati computazionali. Il libro sta iniziando a diventare un po 'datato, in quanto si avvicina a un decennio, quindi non copre metodologie di test più recenti come lo sviluppo guidato dal comportamento. Tuttavia, è la cosa più vicina a un articolo di recensione completo sulla costruzione di software di cui sono a conoscenza. Puoi anche cercare articoli nel software IEEE.

Per quanto riguarda la scienza computazionale, penso che l'articolo migliore sia probabilmente la versione PLoS della prestampa arXiv citata da DavidKetcheson su "Best Practices for Scientific Computing". Dico che proviene da un background ingegneristico, in cui un minor numero di persone cita riferimenti arXiv o pubblica prestampe arXiv, e quindi, citando un "vero articolo di giornale" (mettendo da parte, ovviamente, tutte le questioni relative all'editoria scientifica che sono in discussione in questo momento ) è considerato più favorevolmente (e ho l'impressione che sia per questo che quegli autori hanno scelto di pubblicarlo su una rivista).

Gli autori del documento PLoS che DavidKetcheson e io abbiamo citato fanno parte di un'organizzazione chiamata Software Carpentry che organizza (solitamente 2 giorni) "campi di addestramento " per insegnare agli scienziati alcune migliori pratiche per lo sviluppo del software e utili competenze computazionali per gli scienziati (non solo scienziati computazionali). Il sito Web Software Carpentry ha un'ampia bibliografia relativa allo sviluppo del software in campo scientifico. Se sei interessato a questi problemi, ti incoraggio a contattarli; sono sempre alla ricerca di più sostenitori delle migliori pratiche nello sviluppo di software per fare volontariato in varie capacità. ( Dichiarazione di non responsabilità : faccio volontariato con Software Carpentry.)

Un'altra giustificazione comune per impegnarsi nelle migliori pratiche di sviluppo software è la riproducibilità. Victoria Stodden ha curato un lungo elenco di riferimenti di ricerca riproducibili che potrebbero essere di interesse, a seconda di ciò che vuoi dire.

Non ho riferimenti per l'origine di ciascuna di queste idee / pratiche. Ma ecco alcuni riferimenti molto recenti e pertinenti:

• Cosa rende le librerie di software open source computazionali di successo?
• Best practice per il calcolo scientifico

IMHO Mi occuperei molto di citare "Best Practices" nel contesto di approcci scientificamente provati. La maggior parte delle pratiche deriva da "ciò che sembra funzionare per una serie di progetti da qualcuno percepito come guru coinvolto in tali progetti", piuttosto che derivato da test rigorosi di approcci diversi. Esistono troppe variabili e fattori umani nell'ingegneria del software per affermare che esiste un elenco riferibile di "migliori pratiche" (ad esempio una pratica che funziona su un progetto fallirà completamente su un altro).

Mi approccerei affermando ciò di cui il tuo progetto aveva bisogno, perché ne aveva bisogno e aggiungere riferimenti ai metodi usati e perché li hai usati.

Mi spingerei anche a riferire risultati quantificabili piuttosto che riferimenti per affermare il tuo punto. Ad esempio, se i test della tua unità hanno scoperto 100 bug, 10 dei quali abbastanza gravi da mettere in dubbio il risultato precedentemente pubblicato. Questa è una dichiarazione molto più potente da avere nel tuo dottorato di ricerca rispetto a una dichiarazione che conosci l'origine dei test unitari.

modifica: (errore di battitura fisso) - Rispondendo a quanto segue - Io do spesso crescere bambini come un'analogia con i progetti software. Esistono molti metodi e metodi testati per allevarli, cercando di crescere i tuoi figli con un metodo perché funziona per la media o un sottocampione testato, funzionerà finché il tuo bambino è uguale a quello testato. È meglio conoscere molti metodi e applicare quelli che funzionano nella tua istanza. Sì, i test unitari possono essere dimostrati, ma applicarlo basandosi solo su questo potrebbe significare che il tuo progetto arriva sul mercato in ritardo e quindi non riesce al suo obiettivo (se questo è l'obiettivo). Sto dicendo che applicare un metodo per ottenere un risultato e dare il risultato di tale risultato, secondo me è meglio in una tesi, che elencare le cose che hai provato sulla base di altri progetti - a meno che ovviamente l'argomento della tesi non stia misurando le metodologie :)